{ "@context": { "@version": 1.1, "@vocab": "urn:business-engineer:", "be": "urn:business-engineer:", "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", "rdfs": "http://www.w3.org/2000/01/rdf-schema#", "skos": "http://www.w3.org/2004/02/skos/core#", "owl": "http://www.w3.org/2002/07/owl#", "xsd": "http://www.w3.org/2001/XMLSchema#", "name": "skos:prefLabel", "aliases": { "@id": "skos:altLabel", "@container": "@set" }, "definition": "skos:definition", "subClassOf": { "@id": "rdfs:subClassOf", "@type": "@id" }, "domain": { "@id": "rdfs:domain", "@type": "@id" }, "range": { "@id": "rdfs:range", "@type": "@id" }, "url": { "@id": "rdfs:seeAlso", "@type": "@id" }, "steps": { "@id": "urn:business-engineer:steps", "@container": "@list" }, "requirements": { "@id": "urn:business-engineer:requirements", "@container": "@list" }, "domains": { "@id": "urn:business-engineer:domains", "@type": "@id" }, "usesConcept": { "@id": "urn:business-engineer:usesConcept", "@type": "@id" }, "analyzedThroughClock": { "@id": "urn:business-engineer:analyzedThroughClock", "@type": "@id" }, "sourceEntries": { "@id": "urn:business-engineer:sourceEntries", "@type": "@id" }, "instruments": { "@id": "urn:business-engineer:instruments", "@type": "@id" }, "modes": { "@id": "urn:business-engineer:modes", "@type": "@id" }, "sourceDocument": { "@id": "urn:business-engineer:sourceDocument", "@type": "@id" }, "canonicalModel": { "@id": "urn:business-engineer:canonicalModel", "@type": "@id" }, "sourceEntry": { "@id": "urn:business-engineer:sourceEntry", "@type": "@id" }, "targetModel": { "@id": "urn:business-engineer:targetModel", "@type": "@id" }, "subject": { "@id": "urn:business-engineer:subject", "@type": "@id" }, "predicate": { "@id": "urn:business-engineer:predicate", "@type": "@id" }, "object": { "@id": "urn:business-engineer:object", "@type": "@id" }, "producesArtifact": { "@id": "urn:business-engineer:producesArtifact", "@type": "@id" }, "operationalizes": { "@id": "urn:business-engineer:operationalizes", "@type": "@id" }, "appliesToInstrument": { "@id": "urn:business-engineer:appliesToInstrument", "@type": "@id" }, "usesInstrument": { "@id": "urn:business-engineer:usesInstrument", "@type": "@id" }, "usesModel": { "@id": "urn:business-engineer:usesModel", "@type": "@id" }, "definedByModel": { "@id": "urn:business-engineer:definedByModel", "@type": "@id" }, "threadMembers": { "@id": "urn:business-engineer:threadMembers", "@type": "@id" } }, "@graph": [ { "@id": "urn:business-engineer:release:2.0.0", "@type": [ "OntologyRelease", "owl:Ontology" ], "name": "The Business Engineer: A Reconciled Ontology of Mental Models", "version": "2.0.0", "edition": "2026-09-09", "definition": "Complete supplied baseline, the prior 32-model expansion and the complete supplied 125-entry pack. Earlier synthesis used accessible relevant conversations; this is not an exhaustive archive review. User source wording is preserved; current normalized definitions and boundaries govern application.", "statistics": { "baseSourceEntriesCount": 136, "earlierExpansionEntriesCount": 32, "packSourceEntriesCount": 125, "totalSourceEntriesCount": 293, "canonicalModelsCount": 258, "newCanonicalModelsFromPackCount": 92, "legacyAliasesCount": 2, "packEntriesMappedToExistingMechanismsCount": 33, "packMappingsToPriorCatalogCount": 28, "packConsolidationsWithinPackCount": 5, "instrumentsCount": 17, "operationalModesCount": 12, "domainsCount": 9, "conceptsCount": 44, "rolesCount": 19, "clocksCount": 5, "artifactTypesCount": 17, "practiceRulesCount": 18, "visualStandardsCount": 2, "relationAssertionsCount": 582 }, "identityPolicy": "Canonical model numbers are stable and never reused. Source-qualified identifiers preserve source numbering. Reserved legacy alias numbers 70 and 74 resolve to 47 and 37. Scoped variants are not owl:sameAs.", "semanticPolicy": "This is a documentary and conceptual ontology, not a validated causal model or a closed-world knowledge base. Companion validation imposes application integrity constraints. Ordered procedures use RDF lists." }, { "@id": "urn:business-engineer:KnowledgeObject", "@type": "rdfs:Class", "name": "Knowledge Object" }, { "@id": "urn:business-engineer:Model", "@type": "rdfs:Class", "name": "Model", "subClassOf": [ "urn:business-engineer:KnowledgeObject", "skos:Concept" ] }, { "@id": "urn:business-engineer:Domain", "@type": "rdfs:Class", "name": "Domain", "subClassOf": [ "urn:business-engineer:KnowledgeObject", "skos:Concept" ] }, { "@id": "urn:business-engineer:Concept", "@type": "rdfs:Class", "name": "Concept", "subClassOf": [ "urn:business-engineer:KnowledgeObject", "skos:Concept" ] }, { "@id": "urn:business-engineer:Instrument", "@type": "rdfs:Class", "name": "Instrument", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:OperationalMode", "@type": "rdfs:Class", "name": "Operational Mode", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:ArtifactType", "@type": "rdfs:Class", "name": "Artifact Type", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:Role", "@type": "rdfs:Class", "name": "Role", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:Clock", "@type": "rdfs:Class", "name": "Clock", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:PracticeRule", "@type": "rdfs:Class", "name": "Practice Rule", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:VisualStandard", "@type": "rdfs:Class", "name": "Visual Standard", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:SourceDocument", "@type": "rdfs:Class", "name": "Source Document", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:SourceEntry", "@type": "rdfs:Class", "name": "Source Entry", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:SourceFragment", "@type": "rdfs:Class", "name": "Source Fragment", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:Mapping", "@type": "rdfs:Class", "name": "Mapping", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:RelationAssertion", "@type": "rdfs:Class", "name": "Relation Assertion", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:RelationType", "@type": "rdfs:Class", "name": "Relation Type", "subClassOf": "urn:business-engineer:KnowledgeObject" }, { "@id": "urn:business-engineer:OntologyRelease", "@type": "rdfs:Class", "name": "Ontology Release" }, { "@id": "urn:business-engineer:domains", "@type": "rdf:Property", "name": "domains", "range": "urn:business-engineer:Domain", "domain": "urn:business-engineer:Model" }, { "@id": "urn:business-engineer:usesConcept", "@type": "rdf:Property", "name": "usesConcept", "range": "urn:business-engineer:Concept", "domain": "urn:business-engineer:Model" }, { "@id": "urn:business-engineer:analyzedThroughClock", "@type": "rdf:Property", "name": "analyzedThroughClock", "range": "urn:business-engineer:Clock", "domain": "urn:business-engineer:Model" }, { "@id": "urn:business-engineer:sourceEntries", "@type": "rdf:Property", "name": "sourceEntries", "range": "urn:business-engineer:SourceEntry", "domain": "urn:business-engineer:Model" }, { "@id": "urn:business-engineer:sourceDocument", "@type": "rdf:Property", "name": "sourceDocument", "range": "urn:business-engineer:SourceDocument" }, { "@id": "urn:business-engineer:canonicalModel", "@type": "rdf:Property", "name": "canonicalModel", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:SourceEntry" }, { "@id": "urn:business-engineer:sourceEntry", "@type": "rdf:Property", "name": "sourceEntry", "range": "urn:business-engineer:SourceEntry", "domain": "urn:business-engineer:Mapping" }, { "@id": "urn:business-engineer:targetModel", "@type": "rdf:Property", "name": "targetModel", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:Mapping" }, { "@id": "urn:business-engineer:subject", "@type": "rdf:Property", "name": "subject", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:RelationAssertion" }, { "@id": "urn:business-engineer:predicate", "@type": "rdf:Property", "name": "predicate", "range": "urn:business-engineer:RelationType", "domain": "urn:business-engineer:RelationAssertion" }, { "@id": "urn:business-engineer:object", "@type": "rdf:Property", "name": "object", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:RelationAssertion" }, { "@id": "urn:business-engineer:producesArtifact", "@type": "rdf:Property", "name": "producesArtifact", "range": "urn:business-engineer:ArtifactType", "domain": "urn:business-engineer:Instrument" }, { "@id": "urn:business-engineer:operationalizes", "@type": "rdf:Property", "name": "operationalizes", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:Instrument" }, { "@id": "urn:business-engineer:usesInstrument", "@type": "rdf:Property", "name": "usesInstrument", "range": "urn:business-engineer:Instrument", "domain": "urn:business-engineer:OperationalMode" }, { "@id": "urn:business-engineer:usesModel", "@type": "rdf:Property", "name": "usesModel", "range": "urn:business-engineer:Model", "domain": "urn:business-engineer:OperationalMode" }, { "@id": "urn:business-engineer:appliesToInstrument", "@type": "rdf:Property", "name": "appliesToInstrument", "range": "urn:business-engineer:Instrument", "domain": "urn:business-engineer:PracticeRule" }, { "@id": "urn:business-engineer:model:0001", "@type": "Model", "id": 1, "stableId": "BE-M0001", "name": "BE Thinking OS", "definition": "A repeatable analysis workflow connects structural hypotheses, audience context, evidence, compression and action, then revises the workflow after observing results.", "keyQuestion": "Is this insight structurally grounded, contextually anchored, and deployable — or just interesting?", "form": "framework", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this insight structurally grounded, contextually anchored, and deployable — or just interesting?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:1" ], "sourceComponents": "Structural Filter (framework-first cognition), Contextual Gate (audience + timing + purpose), Compression Engine (minimum viable insight), Deployment Layer (actionable output formatting)", "sourceProcedure": "(1) Receive input/question → (2) Activate structural filter: what system is at play? → (3) Pass through contextual gate: who needs this, why now? → (4) Compress to load-bearing insight → (5) Format for deployment across audiences → (6) Feed output back into the loop for calibration", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:1" ], "modes": [ "urn:business-engineer:mode:strategic" ] }, { "@id": "urn:business-engineer:model:0002", "@type": "Model", "id": 2, "stableId": "BE-M0002", "name": "Structural Thinking as Default", "definition": "Begin with a provisional system hypothesis, identify relationships and feedback, and revise the structure when observations contradict it.", "keyQuestion": "What is the structure here — and does the content confirm or break it?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is the structure here — and does the content confirm or break it?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Treat an initial structure as a revisable hypothesis. Evidence can invalidate the framework itself; do not subordinate inconvenient observations to a preferred model.", "calibration": "Treat an initial structure as a revisable hypothesis. Evidence can invalidate the framework itself; do not subordinate inconvenient observations to a preferred model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:2" ], "sourceComponents": "Framework Primacy (structure before content), System View (parts + relationships + feedback), Pattern Library (accumulated structural templates), Content Subordination (facts serve structure, not the reverse)", "sourceProcedure": "(1) When encountering any new information, pause before reacting → (2) Ask: what system does this belong to? → (3) Identify the structural skeleton: inputs, mechanisms, outputs, feedback → (4) Only then engage with the specific content details → (5) Validate whether the content confirms or challenges the structural hypothesis", "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:2" ] }, { "@id": "urn:business-engineer:model:0003", "@type": "Model", "id": 3, "stableId": "BE-M0003", "name": "Contextual Precision", "definition": "Choose the analysis and output according to the audience, decision, timing and intended use.", "keyQuestion": "For whom, why now, and how will this be used?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "For whom, why now, and how will this be used?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:3" ], "sourceComponents": "Audience Identification (WHO — role, constraints, mental model), Temporal Relevance (WHY NOW — what changed, what's at stake today), Deployment Mode (HOW — decision, strategy, communication, education)", "sourceProcedure": "(1) Before analyzing, explicitly define the audience → (2) Identify the temporal trigger: what made this relevant right now? → (3) Determine the output mode: is this for a decision, a strategy session, a presentation? → (4) Calibrate depth, language, and emphasis to match all three coordinates → (5) Strip anything that doesn't serve the specific context", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:3" ], "modes": [ "urn:business-engineer:mode:lookup" ] }, { "@id": "urn:business-engineer:model:0004", "@type": "Model", "id": 4, "stableId": "BE-M0004", "name": "Meta-Compression", "definition": "Compress an explanation to the smallest set of mechanisms that preserves its reasoning, uncertainty and decision implications.", "keyQuestion": "Can I compress this further without losing the mechanism?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Can I compress this further without losing the mechanism?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:4" ], "sourceComponents": "Conceptual Compression (one-sentence essence), Structural Compression (mechanism in 2-3 steps), Deployment Compression (actionable takeaway in one line), Compression Ratio (how much was removed vs. retained)", "sourceProcedure": "(1) Start with the full analysis → (2) Extract the conceptual core: what is this really about in one sentence? → (3) Compress the mechanism: what causes what in 2-3 steps? → (4) Compress the deployment: what should the operator do? → (5) Test: does the compressed version still carry the structural insight, or has it become a platitude?", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:4" ], "modes": [ "urn:business-engineer:mode:visual" ] }, { "@id": "urn:business-engineer:model:0005", "@type": "Model", "id": 5, "stableId": "BE-M0005", "name": "Layered Output Logic", "definition": "Represent one analysis at several levels of detail while keeping definitions, evidence and conclusions consistent across levels.", "keyQuestion": "Does this analysis work for the strategist, the manager, AND the operator — simultaneously?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this analysis work for the strategist, the manager, AND the operator — simultaneously?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:5" ], "sourceComponents": "Macro Layer (industry/system-level mechanism), Organizational Layer (company/team-level impact), Operator Layer (individual-level action), Vertical Coherence (all three layers tell the same structural story)", "sourceProcedure": "(1) Identify the macro mechanism first — the systemic force at work → (2) Translate downward: how does this mechanism hit a specific organization? → (3) Translate again: what does this mean for the individual operator's next decision? → (4) Verify vertical coherence: do all three layers point in the same direction? → (5) Format output so readers can enter at any layer", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:5" ], "modes": [ "urn:business-engineer:mode:visual" ] }, { "@id": "urn:business-engineer:model:0006", "@type": "Model", "id": 6, "stableId": "BE-M0006", "name": "Pragmatic Rigor", "definition": "Use enough rigor to distinguish decision-relevant alternatives, proportionate to uncertainty, stakes and the cost of delay.", "keyQuestion": "Is every claim in this analysis load-bearing — or am I decorating?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is every claim in this analysis load-bearing — or am I decorating?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:6" ], "sourceComponents": "Load-Bearing Test (does this claim do structural work?), Mechanism Requirement (what causes what?), Feedback Identification (what reinforces or dampens this?), Falsifiability Check (what would disprove this?)", "sourceProcedure": "(1) For every claim in your analysis, apply the load-bearing test: remove it and see if the argument collapses → (2) If the argument survives without it, the claim is decorative — cut it → (3) For surviving claims, verify the causal mechanism is explicit → (4) Identify feedback loops: does this effect amplify or dampen itself? → (5) State what evidence would disprove the claim", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:6" ] }, { "@id": "urn:business-engineer:model:0007", "@type": "Model", "id": 7, "stableId": "BE-M0007", "name": "Edge Framing", "definition": "Find a consequential difference between the prevailing interpretation and a mechanism supported by discriminating evidence.", "keyQuestion": "What has the consensus mispriced, overlooked, or gotten structurally wrong?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What has the consensus mispriced, overlooked, or gotten structurally wrong?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Analytical value depends on better understanding or decisions, not distance from consensus. Confirming a well-supported consensus can be the correct result.", "calibration": "Analytical value depends on better understanding or decisions, not distance from consensus. Confirming a well-supported consensus can be the correct result.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:7" ], "sourceComponents": "Consensus Mapping (what does everyone already believe?), Mispricing Detection (where is the gap between belief and structural reality?), Overlooked Variable Identification (what factor is being systematically ignored?), Contrarian Validation (is the contrarian view structurally supported or just provocative?)", "sourceProcedure": "(1) Map the consensus view on any topic explicitly → (2) Identify the structural assumptions embedded in that consensus → (3) Stress-test each assumption: what would have to be true for this to hold? → (4) Look for the overlooked variable or mispriced factor → (5) Validate: is the edge structural (backed by mechanism) or just rhetorical? → (6) If structural, frame the insight around the gap between consensus and reality", "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:7" ] }, { "@id": "urn:business-engineer:model:0008", "@type": "Model", "id": 8, "stableId": "BE-M0008", "name": "Integration Engine", "definition": "Combine useful models through their explicit assumptions and relationships; shared premises do not provide independent corroboration.", "keyQuestion": "Which domain is driving this outcome — and which domain hasn't caught up yet?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which domain is driving this outcome — and which domain hasn't caught up yet?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:8" ], "sourceComponents": "Technology Layer (capabilities, constraints, trajectories), Economics Layer (costs, margins, incentive structures), Behavior Layer (user psychology, adoption patterns, resistance), Narrative Layer (stories that shape perception and capital flows), Incentive Layer (what actors are actually rewarded for doing)", "sourceProcedure": "(1) Analyze any phenomenon through each of the five lenses independently → (2) Map the interactions: how does technology reshape economics? How do incentives distort narrative? → (3) Identify the dominant layer: which one is driving outcomes right now? → (4) Identify the lagging layer: which one hasn't caught up yet? → (5) The gap between the dominant and lagging layer is where the insight lives", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:8" ], "modes": [ "urn:business-engineer:mode:lookup" ] }, { "@id": "urn:business-engineer:model:0009", "@type": "Model", "id": 9, "stableId": "BE-M0009", "name": "Strategic Narrative Compression", "definition": "Express the mechanism, stakes and action in a coherent narrative without removing qualifications that could change the conclusion.", "keyQuestion": "Have I oriented, illuminated, and activated — or just informed?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Have I oriented, illuminated, and activated — or just informed?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:9" ], "sourceComponents": "Orient Phase (stakes, audience, context — why should they care?), Illuminate Phase (mechanism, causality, structure — what is actually happening?), Activate Phase (implications, decisions, next moves — what should they do?)", "sourceProcedure": "(1) Open by orienting the audience: what's at stake and why it matters now → (2) Illuminate the mechanism: explain the structural driver in 2-3 steps → (3) Activate with implications: give the audience a concrete next move or decision framework → (4) Test: can someone who reads only the Orient phase decide if they need to read further? → (5) Test: can someone who reads only the Activate phase take action?", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:9" ], "modes": [ "urn:business-engineer:mode:visual" ] }, { "@id": "urn:business-engineer:model:0010", "@type": "Model", "id": 10, "stableId": "BE-M0010", "name": "Calibration Loop", "definition": "Compare a prior prediction with the observed result and revise the assumption or model that produced the error.", "keyQuestion": "Is this the sharpest, most precise version of this insight — or can I compress and calibrate further?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this the sharpest, most precise version of this insight — or can I compress and calibrate further?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:10" ], "sourceComponents": "Variant Generation (produce 3-5 versions of the same insight), Sharpness Pass (remove every non-load-bearing word), Contrarian Pass (invert the insight — does the opposite hold?), Compression Pass (cut by 50% — what survives?), Audience Pass (reframe for a different stakeholder)", "sourceProcedure": "(1) State the initial insight → (2) Generate a sharper version: fewer words, more precision → (3) Generate a more contrarian version: what would the strongest critic say? → (4) Generate a more compressed version: cut it in half → (5) Compare all variants: which one is structurally strongest? → (6) Adopt the winner and repeat if needed", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:10" ] }, { "@id": "urn:business-engineer:model:0011", "@type": "Model", "id": 11, "stableId": "BE-M0011", "name": "Structural vs Reactive Thinking", "definition": "Distinguish an event from the system generating it, while allowing events to reveal a structural change.", "keyQuestion": "Am I reacting to the event — or understanding the system that produced it?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I reacting to the event — or understanding the system that produced it?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:11" ], "sourceComponents": "Reactive Chain (Event → Emotional/Surface Response → Action), Structural Chain (Event → What system produced this? → What mechanism is operating? → What are the second-order implications?), Mode Detection (recognizing which mode you are currently in)", "sourceProcedure": "(1) When an event occurs (market move, product launch, policy change), catch yourself before reacting → (2) Ask: what system produced this event? → (3) Identify the mechanism: what causal chain is at work? → (4) Map implications: if this mechanism continues, what happens next? → (5) Only then decide on a response — which now addresses the mechanism, not the symptom", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:11" ] }, { "@id": "urn:business-engineer:model:0012", "@type": "Model", "id": 12, "stableId": "BE-M0012", "name": "Structural Thinking Workflow", "definition": "Map the actor, system boundary, relationships, constraints and interventions, then test the proposed mechanism against alternatives.", "keyQuestion": "What is the binding constraint, and where is the leverage point?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is the binding constraint, and where is the leverage point?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:12" ], "sourceComponents": "Pattern Recognition (recurring signals across domains), Structural Diagnosis (the system architecture that generates the pattern), Constraint Identification (the binding limit on the system), Leverage Point (the high-impact intervention point), Second-Order Implications (downstream effects most analysts miss)", "sourceProcedure": "(1) Observe: collect signals and identify recurring patterns → (2) Diagnose: hypothesize the structural system generating those patterns → (3) Constrain: find the binding constraint — the single factor most limiting the system → (4) Leverage: identify where minimal intervention would shift the most → (5) Project: map second-order implications — the consequences of consequences", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:12" ] }, { "@id": "urn:business-engineer:model:0013", "@type": "Model", "id": 13, "stableId": "BE-M0013", "name": "Reality Gap Analysis", "definition": "Compare stated intentions, visible behavior and underlying incentives to identify consequential gaps between claims and operation.", "keyQuestion": "Where is the gap between what the market believes and what structural forces will deliver?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where is the gap between what the market believes and what structural forces will deliver?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Narratives can alter investment, incentives and the structure itself. Convergence is contingent and may not occur within the decision horizon; do not assert that structure always wins.", "calibration": "Narratives can alter investment, incentives and the structure itself. Convergence is contingent and may not occur within the decision horizon; do not assert that structure always wins.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:13" ], "sourceComponents": "Narrative Layer (what the market/consensus currently believes and prices), Structural Layer (what the underlying forces — capital flows, technology curves, regulatory vectors — actually indicate), Gap Measurement (size and direction of divergence), Convergence Timeline (when reality forces narrative correction)", "sourceProcedure": "(1) Map the dominant narrative: what does the consensus believe about this market/company/trend? → (2) Map the structural forces: capital requirements, technology constraints, regulatory direction, competitive dynamics → (3) Measure the gap: where and how much do narrative and structure diverge? → (4) Estimate convergence: when will reality force a correction? → (5) Position accordingly: the gap IS the insight", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:13" ] }, { "@id": "urn:business-engineer:model:0014", "@type": "Model", "id": 14, "stableId": "BE-M0014", "name": "Hidden Driver Detection", "definition": "Look for overlooked variables or relationships that can explain an observation better than the apparent driver.", "keyQuestion": "What is the existential imperative that makes this decision structurally inevitable?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is the existential imperative that makes this decision structurally inevitable?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Generate competing explanations including mistakes, agency conflicts and incomplete information. Hidden motives and existential imperatives are hypotheses, not facts inferred from a puzzling decision.", "calibration": "Generate competing explanations including mistakes, agency conflicts and incomplete information. Hidden motives and existential imperatives are hypotheses, not facts inferred from a puzzling decision.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:14" ], "sourceComponents": "Layer 1 — Stated Reason (public narrative, press release, earnings call language), Layer 2 — Plausible Reason (informed analyst interpretation, industry logic), Layer 3 — Structural Driver (existential constraint, competitive imperative, survival logic)", "sourceProcedure": "(1) Note the stated reason for any major decision → (2) Apply analyst logic: what's the plausible business reason? → (3) Go deeper: what existential threat or structural constraint makes this decision inevitable? → (4) Test Layer 3 by asking: \"Would they do this even if the stated and plausible reasons were false?\" → (5) If yes, you've found the structural driver", "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:14" ] }, { "@id": "urn:business-engineer:model:0015", "@type": "Model", "id": 15, "stableId": "BE-M0015", "name": "Constraint Mapping", "definition": "Identify which resource, rule, authority or dependency limits a specified outcome under current conditions.", "keyQuestion": "What is the single binding constraint — and what happens if it's relaxed or tightened?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is the single binding constraint — and what happens if it's relaxed or tightened?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Find the constraint or jointly binding set relevant to a stated objective and horizon. A bottleneck need not also be irreplaceable and possess veto power. Model 130 explicitly permits simultaneous constraints.", "calibration": "Find the constraint or jointly binding set relevant to a stated objective and horizon. A bottleneck need not also be irreplaceable and possess veto power. Model 130 explicitly permits simultaneous constraints.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:15" ], "sourceComponents": "Bottleneck Test (scale 10x — what breaks first?), Substitution Test (can this factor be replaced or routed around?), Veto Test (who or what has unilateral blocking power?), Binding Constraint (the one constraint that all three tests point to)", "sourceProcedure": "(1) List all apparent constraints on the system → (2) Apply the Bottleneck Test to each: if this system scaled 10x, which constraint would break first? → (3) Apply the Substitution Test: which of these constraints is truly irreplaceable? → (4) Apply the Veto Test: who or what can single-handedly block progress? → (5) The constraint that fails all three tests (breaks first, can't be substituted, has veto power) is the binding constraint → (6) All strategy should address this constraint first", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:15" ], "modes": [ "urn:business-engineer:mode:strategic" ] }, { "@id": "urn:business-engineer:model:0016", "@type": "Model", "id": 16, "stableId": "BE-M0016", "name": "Power Distribution Analysis", "definition": "Map who can allocate resources, set terms, withhold permission or redirect value, and how those powers depend on others.", "keyQuestion": "Who can block, who can force, and who can rewrite the rules — and are they the same actor?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who can block, who can force, and who can rewrite the rules — and are they the same actor?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:16" ], "sourceComponents": "Veto Power (capacity to block without offering alternatives), Compulsion Power (capacity to force action — regulatory, financial, contractual), Rule-Making Power (capacity to redefine the game — platform rules, standards, regulations), Power Map (visual distribution of all three types across actors)", "sourceProcedure": "(1) Identify all actors in the system → (2) For each actor, assess: can they block outcomes (veto)? → (3) Can they force action (compulsion)? → (4) Can they change the rules (rule-making)? → (5) Map the distribution: who holds which types of power? → (6) Identify the dominant power holder — the actor with the most types or the most consequential type → (7) Strategy must account for or work through the dominant power holder", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:16" ], "modes": [ "urn:business-engineer:mode:strategic" ] }, { "@id": "urn:business-engineer:model:0017", "@type": "Model", "id": 17, "stableId": "BE-M0017", "name": "System Fragmentation Mapping", "definition": "Locate disconnected responsibilities, information or processes whose interfaces create cost, failure or an integration opportunity.", "keyQuestion": "Is this system genuinely integrated — or is the integration cosmetic?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this system genuinely integrated — or is the integration cosmetic?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:17" ], "sourceComponents": "Visible Integration (real coordination, shared data, unified incentives), Hidden Fragmentation (separate systems behind unified interface), Cosmetic Integration (shared brand/narrative but independent operations), Deep Fragmentation (fundamentally separate with no real connection), Fragmentation Score (assessment of true integration level)", "sourceProcedure": "(1) Take any system that appears integrated (a conglomerate, a platform, a market) → (2) Test data flow: does information actually move across units in real time? → (3) Test incentive alignment: are all parts rewarded for the same outcomes? → (4) Test operational dependency: would removing one part break the others? → (5) Classify each connection as visible, hidden, cosmetic, or deeply fragmented → (6) The true fragmentation level reveals vulnerability and opportunity", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:17" ] }, { "@id": "urn:business-engineer:model:0018", "@type": "Model", "id": 18, "stableId": "BE-M0018", "name": "Structural Reality Framework", "definition": "Reconstruct a system from constraints, incentives, power, dependencies and observable behavior rather than relying on its public description.", "keyQuestion": "What higher-layer constraints am I ignoring that will override my market-level analysis?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What higher-layer constraints am I ignoring that will override my market-level analysis?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Use geopolitics, policy, infrastructure and markets as interacting layers. Draw feedback upward as well as constraints downward; no universal hierarchy resolves every case.", "calibration": "Use geopolitics, policy, infrastructure and markets as interacting layers. Draw feedback upward as well as constraints downward; no universal hierarchy resolves every case.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:18" ], "sourceComponents": "Geopolitical Layer (international power, alliances, conflicts, resource control), Policy Layer (regulation, taxation, subsidies, trade rules), Infrastructure Layer (physical systems, supply chains, digital networks, energy grids), Market Layer (prices, competition, business models, consumer behavior)", "sourceProcedure": "(1) Start at the top: what are the geopolitical forces relevant to this issue? → (2) Move to policy: how have those geopolitical forces shaped or constrained government action? → (3) Move to infrastructure: what physical/digital systems enable or limit execution? → (4) Finally reach markets: how do all three layers above constrain what businesses can actually do? → (5) Never analyze a lower layer without checking the constraints imposed by all layers above", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:18" ] }, { "@id": "urn:business-engineer:model:0019", "@type": "Model", "id": 19, "stableId": "BE-M0019", "name": "Constraint Cascade Principle", "definition": "Removing one limiting constraint can expose another; model the next binding constraint and possible simultaneous limits before investing.", "keyQuestion": "Is there an upstream constraint that makes all my downstream optimization pointless?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is there an upstream constraint that makes all my downstream optimization pointless?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Upstream constraints can dominate, but not always. Test their actual causal reach, the available adaptations and the consequences of downstream failure; avoid a fixed lethality ranking.", "calibration": "Upstream constraints can dominate, but not always. Test their actual causal reach, the available adaptations and the consequences of downstream failure; avoid a fixed lethality ranking.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:19" ], "sourceComponents": "Upstream Audit (geopolitical and policy alignment check), Downstream Assessment (competitive and operational efficiency), Cascade Direction (problems always flow downward from higher layers), Lethality Ranking (geopolitical misalignment > policy misalignment > infrastructure gaps > competitive weakness)", "sourceProcedure": "(1) Before any competitive analysis, check the geopolitical layer: is the environment stable? → (2) Check the policy layer: are regulations enabling or blocking? → (3) Check the infrastructure layer: can the physical/digital systems support the strategy? → (4) Only then assess competitive positioning → (5) If any upstream layer is misaligned, fixing downstream layers is futile — address the cascade from the top", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:19" ] }, { "@id": "urn:business-engineer:model:0020", "@type": "Model", "id": 20, "stableId": "BE-M0020", "name": "Perspective-First Analysis", "definition": "State whose decision and exposure the analysis serves, then inspect the same system from other consequential positions.", "keyQuestion": "Do I understand the territory well enough to know what to measure — or am I measuring blindly?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Do I understand the territory well enough to know what to measure — or am I measuring blindly?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:20" ], "sourceComponents": "Qualitative Territory Scan (observe, listen, pattern-match before measuring), Hypothesis Generation (form structural hypotheses from qualitative understanding), Targeted Measurement Design (design data collection to test specific hypotheses), Perspective-Data Feedback (let measurement refine perspective, let perspective redirect measurement)", "sourceProcedure": "(1) Before pulling data, spend time understanding the territory qualitatively: who are the players, what are the dynamics, what feels off? → (2) Generate 2-3 structural hypotheses about what's driving outcomes → (3) Design targeted measurements that would confirm or falsify each hypothesis → (4) Collect and analyze only that data → (5) Let the results refine your perspective, then iterate", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:20" ] }, { "@id": "urn:business-engineer:model:0021", "@type": "Model", "id": 21, "stableId": "BE-M0021", "name": "Territory Mapping", "definition": "Map the relevant market terrain, actors, interfaces and constraints before choosing a strategic route.", "keyQuestion": "What game is being played, by whom, driven by what, and shaped by which structural forces?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What game is being played, by whom, driven by what, and shaped by which structural forces?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:21" ], "sourceComponents": "Game Identification (what type of competition is this — zero-sum, positive-sum, infinite?), Player Mapping (who has real power, not just visibility), Behavior Drivers (incentives, constraints, fears that determine action), Structural Forces (technology, capital, regulation, demographics shaping the landscape)", "sourceProcedure": "(1) Ask: what game is being played here? Is it winner-take-all, cooperative, or something else? → (2) Map the real players: who has veto, compulsion, or rule-making power? → (3) Identify behavior drivers: what are the key actors actually incentivized to do? → (4) Map structural forces: which large-scale trends are shaping the playing field? → (5) Synthesize: the intersection of game type, player incentives, and structural forces reveals the true territory", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:21" ] }, { "@id": "urn:business-engineer:model:0022", "@type": "Model", "id": 22, "stableId": "BE-M0022", "name": "Grand Strategy Framework", "definition": "Connect a long-term objective to the terrain, resources, capabilities, sequencing and adaptation needed to reach it.", "keyQuestion": "Am I building strategy from territory understanding — or am I guessing the territory from my preferred tactics?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I building strategy from territory understanding — or am I guessing the territory from my preferred tactics?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:22" ], "sourceComponents": "Territory (deep understanding of the actual competitive, technological, and regulatory landscape), Map (the strategic interpretation — your reading of the territory that guides resource allocation), Routes (tactical execution paths — the specific moves, sequences, and contingencies)", "sourceProcedure": "(1) Invest heavily in territory understanding: what is the actual landscape? Use Territory Mapping, Structural Reality Framework, and Constraint Mapping → (2) Derive your map: based on the territory, what is your strategic interpretation? Where are the opportunities, threats, and leverage points? → (3) Design routes: what specific tactical paths will you take? In what sequence? With what contingencies? → (4) Continuously update: as the territory shifts, the map must shift, and routes must adapt", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:22" ] }, { "@id": "urn:business-engineer:model:0023", "@type": "Model", "id": 23, "stableId": "BE-M0023", "name": "Time Horizon Analysis", "definition": "Separate decisions by the time needed to act, learn, recover investment and reverse a mistake.", "keyQuestion": "Am I managing all three time horizons simultaneously — or sacrificing the future for the present (or vice versa)?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I managing all three time horizons simultaneously — or sacrificing the future for the present (or vice versa)?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The stated horizon lengths are examples. Choose horizons around the actual asset life, decision window and uncertainty-resolution schedule.", "calibration": "The stated horizon lengths are examples. Choose horizons around the actual asset life, decision window and uncertainty-resolution schedule.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:23" ], "sourceComponents": "Immediate Horizon (0-2yr: current revenue, operational execution, quick wins), Mid-Term Horizon (3-5yr: market positioning, capability building, competitive moats), Long-Term Horizon (6-10+yr: structural bets, technology shifts, ecosystem evolution), Horizon Balancing (managing all three simultaneously without neglecting any)", "sourceProcedure": "(1) For any strategic question, explicitly analyze across all three horizons → (2) Immediate: what must we do in the next 0-2 years to survive and generate cash? → (3) Mid-Term: what capabilities and positions must we build in 3-5 years? → (4) Long-Term: what structural bets should we place for 6-10+ years? → (5) Check for conflicts: does the immediate plan undermine the long-term bet? → (6) Allocate attention and resources across all three", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:23" ] }, { "@id": "urn:business-engineer:model:0024", "@type": "Model", "id": 24, "stableId": "BE-M0024", "name": "Contextual Map (2x2)", "definition": "Use two explicit, decision-relevant axes to compare positions; the map is a simplification whose dimensions and boundaries must be justified.", "keyQuestion": "Am I allocating resources based on the actual combination of impact and uncertainty — or defaulting to what feels safe?", "form": "framework", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I allocating resources based on the actual combination of impact and uncertainty — or defaulting to what feels safe?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:24" ], "sourceComponents": "Invest Quadrant (high strategic impact + low uncertainty = commit fully), Hedge Quadrant (high strategic impact + high uncertainty = maintain optionality, place calculated bets), Track Quadrant (low strategic impact + low uncertainty = monitor with minimal resources), Scout Quadrant (low strategic impact + high uncertainty = cheap exploration, watch for signals)", "sourceProcedure": "(1) List all strategic initiatives, trends, or decisions on the table → (2) Rate each on Strategic Impact (how much does this affect our future?) and Uncertainty (how confident are we in the outcome?) → (3) Place each in the appropriate quadrant → (4) Invest: allocate significant resources now → Hedge: build optionality, don't commit fully → Track: maintain awareness with minimal cost → Scout: run cheap experiments, watch for signal changes → (5) Reassess quarterly — quadrant placement shifts as uncertainty resolves", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:24" ] }, { "@id": "urn:business-engineer:model:0025", "@type": "Model", "id": 25, "stableId": "BE-M0025", "name": "Tactical Routes Framework", "definition": "Translate a strategic destination into feasible alternative routes with milestones, dependencies and fallback choices.", "keyQuestion": "Does my tactical route match my actual assessment — or my ambition?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my tactical route match my actual assessment — or my ambition?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:25" ], "sourceComponents": "External Assessment (market, competition, technology, regulation), Internal Assessment (capabilities, resources, culture, leadership), Constraint Assessment (time, capital, talent, regulatory limits), Route Selection (Vertical: deepen / Horizontal: broaden / Diagonal: both / Combination: orchestrated sequence)", "sourceProcedure": "(1) Conduct external assessment: what does the market, competitive, and regulatory landscape look like? → (2) Conduct internal assessment: what are our real capabilities, not aspirational ones? → (3) Map constraints: what are the hard limits on time, capital, talent? → (4) Select the route that matches the assessment: vertical if depth is the advantage, horizontal if breadth, diagonal if speed demands both, combination if resources allow orchestration → (5) Sequence and execute", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:25" ] }, { "@id": "urn:business-engineer:model:0026", "@type": "Model", "id": 26, "stableId": "BE-M0026", "name": "Multi-Horizon Strategic Map", "definition": "Connect near-term execution, medium-term capability building and longer-term options without assuming one horizon determines another.", "keyQuestion": "Is my resource allocation balanced across all three horizons — or has the immediate consumed everything?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my resource allocation balanced across all three horizons — or has the immediate consumed everything?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The 70/20/10 allocation is illustrative, not an optimized or universal recommendation. Resource allocation depends on survival needs, opportunity quality, constraints and risk.", "calibration": "The 70/20/10 allocation is illustrative, not an optimized or universal recommendation. Resource allocation depends on survival needs, opportunity quality, constraints and risk.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:26" ], "sourceComponents": "70% Immediate Allocation (operations, current revenue, optimization), 20% Mid-Term Allocation (new capabilities, market positioning, competitive moats), 10% Long-Term Allocation (moonshots, structural bets, transformation), Simultaneous Execution (all three run in parallel, not in sequence), Ratio Review (quarterly adjustment based on changing conditions)", "sourceProcedure": "(1) Audit current resource allocation: where is time, money, and talent actually going? → (2) Redistribute toward the 70/20/10 target → (3) Ensure each allocation has a clear owner and success metrics → (4) Run all three in parallel — do not wait for immediate results before starting mid-term → (5) Review the ratio quarterly: a crisis may justify 90/8/2; a stable period may allow 60/25/15 → (6) Never let any horizon go to zero", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:runtime" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:26" ] }, { "@id": "urn:business-engineer:model:0027", "@type": "Model", "id": 27, "stableId": "BE-M0027", "name": "Contextual Adaptability Framework", "definition": "Adapt a strategy when its contextual assumptions change, using explicit signals rather than reacting to every fluctuation.", "keyQuestion": "Are we fit for the current environment AND the one that's emerging — or only the one we grew up in?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Are we fit for the current environment AND the one that's emerging — or only the one we grew up in?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:27" ], "sourceComponents": "Forces Assessment (what external pressures — technological, regulatory, competitive, social — are shifting?), Capability Assessment (does the organization have the skills, structure, and culture to respond?), Horizon Assessment (is the organization looking far enough ahead to anticipate shifts?), Adaptability Score (composite fitness across all three dimensions)", "sourceProcedure": "(1) Map current forces: what external pressures are actively shifting? → (2) Assess capabilities: can the organization respond to these shifts with current skills and structure? → (3) Assess horizons: is the organization tracking emerging forces, not just current ones? → (4) Identify the weakest dimension — that's the vulnerability → (5) Design interventions to strengthen the weakest dimension before a crisis forces it → (6) Reassess as the environment shifts", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:27" ] }, { "@id": "urn:business-engineer:model:0028", "@type": "Model", "id": 28, "stableId": "BE-M0028", "name": "Strategy Lever Framework", "definition": "Find interventions that can materially change a strategic outcome and assess their feasibility, cost and second-order effects.", "keyQuestion": "Am I starting small enough — or am I trying to scale before I've proven value to the tightest possible audience?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I starting small enough — or am I trying to scale before I've proven value to the tightest possible audience?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:28" ], "sourceComponents": "Blue Sea (identify premium niche where competition is thin), Niche Down (select the tightest segment within that niche), MVA (define the smallest audience that sustains the business), Adjacent Niches (map neighboring segments for systematic expansion), Scale (build the infrastructure and model for broader reach)", "sourceProcedure": "(1) Scan the landscape for underserved premium niches (Blue Sea) → (2) Within that niche, identify the tightest coherent segment you can dominate (Niche Down) → (3) Define the Minimum Viable Audience — the smallest group whose problem you can solve profitably (MVA) → (4) Serve them obsessively until you have proof of value → (5) Map adjacent niches and expand using existing credibility → (6) Only scale when the model has been validated across multiple niches", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:28" ] }, { "@id": "urn:business-engineer:model:0029", "@type": "Model", "id": 29, "stableId": "BE-M0029", "name": "Blue Sea Strategy", "definition": "Seek a defensible space where a specific audience is underserved and the business can offer differentiated value economically.", "keyQuestion": "Where can I find the smallest premium niche where I have a structural advantage from day one?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where can I find the smallest premium niche where I have a structural advantage from day one?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Premium niches can create focus but do not automatically produce high margins or defensibility. Verify reachable demand, willingness to pay, delivery economics and competitive response.", "calibration": "Premium niches can create focus but do not automatically produce high margins or defensibility. Verify reachable demand, willingness to pay, delivery economics and competitive response.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:29" ], "sourceComponents": "Premium Niche Identification (where can you charge premium prices to a small, underserved group?), Structural Advantage Check (what gives you a natural edge in this niche?), Organic Expansion Path (how does this niche connect to adjacent markets?), Capital Efficiency (high margins early, self-funded growth)", "sourceProcedure": "(1) Instead of looking for empty markets, look for small markets where premium customers are underserved → (2) Verify structural advantage: why can you serve this niche better than anyone else? → (3) Enter with a premium offering: charge high, serve few, learn fast → (4) Use early margins to fund expansion into adjacent niches → (5) Never try to go mass-market before the premium niche is dominant and profitable", "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:29" ] }, { "@id": "urn:business-engineer:model:0030", "@type": "Model", "id": 30, "stableId": "BE-M0030", "name": "Minimum Viable Audience (MVA)", "definition": "Start with the smallest audience that can sustain useful learning and a viable economic wedge.", "keyQuestion": "Who are the fewest people who need this most urgently — and can they sustain the business?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who are the fewest people who need this most urgently — and can they sustain the business?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:30" ], "sourceComponents": "Audience Precision (demographic, psychographic, and behavioral specificity), Urgency Test (is the problem urgent enough to drive purchase without persuasion?), Sustainability Test (can this group generate enough revenue to sustain the business?), Feedback Density (is the audience accessible enough for rapid iteration?)", "sourceProcedure": "(1) Start with an existing market, not a hypothetical one → (2) Zoom in: who within this market has the most urgent, specific, underserved problem? → (3) Define the MVA: the smallest group whose urgency, willingness to pay, and accessibility are all high → (4) Test: can this group sustain the business at premium pricing? → (5) Serve them with obsessive focus until they become advocates → (6) Let the MVA define the product, not the other way around", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:30" ] }, { "@id": "urn:business-engineer:model:0031", "@type": "Model", "id": 31, "stableId": "BE-M0031", "name": "Niche-to-Microniche Strategy", "definition": "Narrow a market to a group with a shared problem, reachable distribution and a specific reason to choose the offer.", "keyQuestion": "Is my target segment small enough for fast feedback and proof of value — or too broad for either?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my target segment small enough for fast feedback and proof of value — or too broad for either?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:31" ], "sourceComponents": "Microniche Definition (the smallest coherent segment with a shared, specific problem), Feedback Loop Speed (how quickly can you learn from this group?), Proof of Value (can you demonstrate undeniable results for this segment?), Launchpad Potential (does mastering this microniche unlock adjacent segments?)", "sourceProcedure": "(1) Take your niche and ask: can I make this smaller and more specific? → (2) Define the microniche: a group so tight you can know every member by name → (3) Enter with a hyper-specific offer tailored to their exact problem → (4) Maximize feedback loop speed: talk to every user, iterate daily → (5) Achieve proof of value: measurable results that are undeniable → (6) Use the proof of value to expand to adjacent microniches", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:31" ] }, { "@id": "urn:business-engineer:model:0032", "@type": "Model", "id": 32, "stableId": "BE-M0032", "name": "Adjacent Niche Expansion", "definition": "Expand into an adjacent audience when transferable capabilities and distribution outweigh the additional complexity.", "keyQuestion": "Which adjacent niche can I enter where my existing advantage, infrastructure, and brand credibility transfer most naturally?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which adjacent niche can I enter where my existing advantage, infrastructure, and brand credibility transfer most naturally?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:32" ], "sourceComponents": "Proximity Mapping (which niches share enough DNA with the current one?), Advantage Transfer Test (does our competitive edge carry over?), Infrastructure Leverage (can we serve the new niche with existing systems?), Brand Permission (does the market believe we belong here?)", "sourceProcedure": "(1) Map all segments adjacent to your current niche → (2) For each, test proximity: does our core advantage transfer? → (3) Test infrastructure leverage: can we serve this segment without major new investment? → (4) Test brand permission: does our reputation in the current niche give us credibility here? → (5) Prioritize the adjacent niche that scores highest on all three → (6) Enter with a tailored offer, not a copy of the current one → (7) Repeat the cycle from each new niche", "usesConcept": [ "urn:business-engineer:concept:portability", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:32" ] }, { "@id": "urn:business-engineer:model:0033", "@type": "Model", "id": 33, "stableId": "BE-M0033", "name": "Transitional Business Model", "definition": "Use a temporary business model to acquire resources or learning for a more durable model, with explicit transition conditions.", "keyQuestion": "Is my current business model still fit for this growth stage — or am I clinging to the model that got me here?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my current business model still fit for this growth stage — or am I clinging to the model that got me here?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Business-model changes may be needed at growth transitions; they are not mandatory at numerical 0-to-1, 1-to-10 or 10-to-100 boundaries. Diagnose actual model fit.", "calibration": "Business-model changes may be needed at growth transitions; they are not mandatory at numerical 0-to-1, 1-to-10 or 10-to-100 boundaries. Diagnose actual model fit.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:33" ], "sourceComponents": "Stage Recognition (what growth stage are you in — 0→1, 1→10, 10→100?), Model Fitness (is the current model still fit for the current stage?), Transformation Triggers (what signals indicate the model must change?), Mindset Shift (how must the leadership mindset evolve?), Org Design Shift (how must the organizational structure change?)", "sourceProcedure": "(1) Honestly assess your current growth stage → (2) Evaluate model fitness: is the current model generating increasing or decreasing returns? → (3) Watch for transformation triggers: plateauing growth, increasing friction, talent misalignment → (4) When triggers appear, redesign the business model for the next stage → (5) Simultaneously evolve mindset (from founder to CEO to architect) and org design (from flat to layered to networked) → (6) Expect this transformation to be uncomfortable — it means the system is working", "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:33" ] }, { "@id": "urn:business-engineer:model:0034", "@type": "Model", "id": 34, "stableId": "BE-M0034", "name": "Business Scaling Framework", "definition": "Expand demand and operating capacity while monitoring unit economics, coordination costs and service quality.", "keyQuestion": "Are my product, business model, and org design all aligned for the next stage of scale — or is one lagging?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Are my product, business model, and org design all aligned for the next stage of scale — or is one lagging?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:34" ], "sourceComponents": "Product Scaling (does the product serve wider segments without degrading quality?), Business Model Scaling (do unit economics improve or at least hold with volume?), Org Design Scaling (can the organization execute at higher volume without chaos?), Alignment Check (are all three dimensions scaling in sync?)", "sourceProcedure": "(1) Assess product: can it serve the next wider segment without custom work or quality degradation? → (2) Assess business model: do unit economics improve with scale, or do hidden costs emerge? → (3) Assess org design: can the team execute at 10x volume without breaking? → (4) Identify the lagging dimension — the one that cannot keep up → (5) Fix the lagging dimension before attempting to scale further → (6) Scale only when all three dimensions are aligned", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:34" ] }, { "@id": "urn:business-engineer:model:0035", "@type": "Model", "id": 35, "stableId": "BE-M0035", "name": "Scalability Matrix", "definition": "Compare growth opportunities by their demand potential and the operating constraints that determine scalable delivery.", "keyQuestion": "What is my real error cost and feedback speed — and is my scaling approach appropriate for that combination?", "form": "framework", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is my real error cost and feedback speed — and is my scaling approach appropriate for that combination?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "High error cost and slow feedback make rapid scaling difficult, not inherently impossible. Assess process redesign, instrumentation, controls and the benefits of controlled scale.", "calibration": "High error cost and slow feedback make rapid scaling difficult, not inherently impossible. Assess process redesign, instrumentation, controls and the benefits of controlled scale.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:35" ], "sourceComponents": "Optimal Quadrant (low error cost + fast feedback → scale aggressively, iterate fast), Constrained Quadrant (low error cost + slow feedback → scale patiently, await results), Controlled Quadrant (high error cost + fast feedback → scale with safety systems, monitor closely), Non-Scalable Quadrant (high error cost + slow feedback → do not force scale, focus on quality)", "sourceProcedure": "(1) Assess your business: what is the cost of an error at scale? → (2) Assess feedback loop speed: how quickly do you learn if something went wrong? → (3) Plot your position on the matrix → (4) If Optimal: pour fuel on the fire → If Constrained: scale but be patient → If Controlled: scale with guardrails → If Non-Scalable: stop trying to force scale and compete on quality → (5) Reassess as the business evolves — quadrant position can shift", "usesConcept": [ "urn:business-engineer:concept:constraint" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:35" ] }, { "@id": "urn:business-engineer:model:0036", "@type": "Model", "id": 36, "stableId": "BE-M0036", "name": "Fractal Market Expansion", "definition": "Replicate a working market pattern across smaller or adjacent units while testing which contextual differences break replication.", "keyQuestion": "Does my winning pattern repeat at the next scale — and what dynamics change as I grow?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my winning pattern repeat at the next scale — and what dynamics change as I grow?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:36" ], "sourceComponents": "Pattern Identification (what works at the micro level?), Scale Testing (does the pattern repeat at the next level up?), Dynamic Adaptation (how do dynamics change with scale — speed, competition, capital requirements?), Controlled Expansion (expand one scale level at a time, validating pattern persistence)", "sourceProcedure": "(1) Identify the pattern that drives success at your current micro level → (2) Hypothesize: will this pattern repeat at the next scale? → (3) Test at the next scale with controlled expansion → (4) Observe: does the pattern hold, or do new dynamics emerge? → (5) Adapt execution for the new scale's unique characteristics → (6) Repeat: expand one level at a time, validating pattern persistence at each step", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:36" ] }, { "@id": "urn:business-engineer:model:0037", "@type": "Model", "id": 37, "stableId": "BE-M0037", "name": "Speed-Reversibility Matrix", "definition": "Choose an action's speed and commitment according to reversibility, learning value, downside and the cost of delay.", "keyQuestion": "Is this decision high-impact and irreversible (deliberate) — or low-impact and reversible (just do it)?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this decision high-impact and irreversible (deliberate) — or low-impact and reversible (just do it)?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:37", "base:74" ], "sourceComponents": "Strategic Deliberation (high impact + low reversibility → slow down, analyze deeply, consult widely), Smart Experimentation (high impact + high reversibility → move quickly, learn from outcomes, adjust), Careful Consideration (low impact + low reversibility → apply appropriate diligence), Rapid Iteration (low impact + high reversibility → execute immediately, iterate from results)", "sourceProcedure": "(1) For any pending decision, assess: how high is the impact if this goes wrong? → (2) Assess: how easily can this be reversed or corrected? → (3) Plot the decision on the matrix → (4) Match your decision speed and rigor to the quadrant → (5) The most common errors: treating reversible decisions as irreversible (paralysis), and treating irreversible decisions as reversible (recklessness) → (6) Review: are you consistently in the right quadrant for each decision type?", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:reversibility" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:37", "urn:business-engineer:source-entry:base:74" ] }, { "@id": "urn:business-engineer:model:0038", "@type": "Model", "id": 38, "stableId": "BE-M0038", "name": "Moat Hierarchy (Level 1/2/3)", "definition": "Classify sources of defensibility by their mechanism and durability, without assuming a universal ordering across markets.", "keyQuestion": "Do my moats compound with every user interaction — or are they static and erodible?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Do my moats compound with every user interaction — or are they static and erodible?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Static, dynamic and interaction moats are analytical categories, not a universal durability ranking. Brand, scale, exclusive assets and regulatory position can remain durable. Compounding interaction moats are neither necessary nor automatically sufficient.", "calibration": "Static, dynamic and interaction moats are analytical categories, not a universal durability ranking. Brand, scale, exclusive assets and regulatory position can remain durable. Compounding interaction moats are neither necessary nor automatically sufficient.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:38" ], "sourceComponents": "Level 1 — Static Moats (brand recognition, scale economies, patents, regulatory capture — real but decaying without reinforcement), Level 2 — Dynamic Moats (network effects, switching costs, ecosystem lock-in — stronger but can be disrupted by paradigm shifts), Level 3 — Compounding Interaction Moats (every user interaction improves the product, trains the model, or deepens the data advantage — the moat widens automatically)", "sourceProcedure": "(1) Classify your current moats: are they Level 1, 2, or 3? → (2) Level 1 moats buy time but do not compound — use them to build higher levels → (3) Level 2 moats are strong but can be disrupted by platform shifts — monitor for paradigm changes → (4) Level 3 moats are the target: design systems where every user interaction makes the product better for all users → (5) If you lack Level 3, your long-term defensibility in AI is at risk → (6) Build from Level 1 → 2 → 3 sequentially", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:residual-value" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:38" ], "modes": [ "urn:business-engineer:mode:strategic" ] }, { "@id": "urn:business-engineer:model:0039", "@type": "Model", "id": 39, "stableId": "BE-M0039", "name": "Five Defensible Moats in AI", "definition": "Assess AI defensibility through distinct sources of advantage such as distribution, proprietary inputs, integration and network effects; test each locally.", "keyQuestion": "Which of the five AI moats am I building — and is it the right one for my capabilities?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of the five AI moats am I building — and is it the right one for my capabilities?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Treat the five types as a useful set, not an exhaustive list. Domain specialization and data scale can be replicated; test exclusivity, learning value, substitutes, retention and economics.", "calibration": "Treat the five types as a useful set, not an exhaustive list. Domain specialization and data scale can be replicated; test exclusivity, learning value, substitutes, retention and economics.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:39" ], "sourceComponents": "Data Network Effects (usage → data → model improvement → more usage), Community (user-generated content, peer support, identity, switching costs), Specialization Depth (domain expertise, vertical data, custom models), Workflow Lock-in (deep integration into daily operations, high switching cost), Enterprise Relationships (trust, compliance, multi-year contracts, relationship depth)", "sourceProcedure": "(1) Assess which of the five moats your business can realistically build → (2) Match to your current capabilities: data-rich companies start with data network effects; domain experts start with specialization depth → (3) Build one moat to critical mass before layering a second → (4) Monitor vulnerability: data moats are vulnerable to synthetic data; community moats are vulnerable to platform shifts → (5) The strongest position layers 2-3 moats that reinforce each other", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:39" ] }, { "@id": "urn:business-engineer:model:0040", "@type": "Model", "id": 40, "stableId": "BE-M0040", "name": "Compound Moat Strategy", "aliases": [ "Collection Becomes Cash (The Second Climb)" ], "definition": "Reinforcing advantages can compound when one moat finances, strengthens or protects another; demonstrate the link rather than counting labels.", "keyQuestion": "Is my first moat's flywheel spinning before I try to build a second — or am I diluting investment across multiple unproven moats?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my first moat's flywheel spinning before I try to build a second — or am I diluting investment across multiple unproven moats?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Sequential moat building is a resource-allocation heuristic. Some complements must be developed together; compounded advantage is not necessarily exponential.", "calibration": "Sequential moat building is a resource-allocation heuristic. Some complements must be developed together; compounded advantage is not necessarily exponential.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:173", "name": "Rent-Funded Moat Expansion", "definition": "A scarce or defended position can generate cash that funds expansion, debt reduction or shareholder returns; test whether reinvestment creates a reinforcing advantage.", "evidence": "Trace operating cash conversion, capex, net debt, dilution and per-share outcomes alongside the new capability's retention and bargaining effects.", "falsifier": "Persistent subsidy, poor cash conversion or dilution without incremental advantage weakens the compound-moat thesis.", "limits": "Cash accumulation, deleveraging and a new moat are distinct outcomes; adjacency and available cash alone do not establish reinforcement.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:40", "pack:173" ], "sourceComponents": "Primary Moat Selection (which moat matches current capabilities best?), Flywheel Establishment (has the primary moat reached self-reinforcing critical mass?), Adjacent Moat Selection (which second moat is most naturally reinforced by the first?), Compound Effect (how does the combination create defense greater than the sum?)", "sourceProcedure": "(1) Assess your capabilities: what moat can you build fastest? → (2) Invest concentrated resources to establish that moat's flywheel → (3) Test for flywheel: is the moat self-reinforcing? Are you gaining strength without proportional effort? → (4) Once the first flywheel spins, select the adjacent moat that the first most naturally supports → (5) Build the second moat using the advantages from the first → (6) The compound of two spinning flywheels creates a defensible position that's exponentially harder to attack", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:40", "urn:business-engineer:source-entry:pack:173" ] }, { "@id": "urn:business-engineer:model:0041", "@type": "Model", "id": 41, "stableId": "BE-M0041", "name": "The Survival Test", "definition": "Stress a business under adverse competition, funding or technology changes to identify what sustains it and what would make it fail.", "keyQuestion": "If the most powerful competitor copied us tomorrow, would our users stay — and what specifically would keep them?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "If the most powerful competitor copied us tomorrow, would our users stay — and what specifically would keep them?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Use a plausible funded competitor response and a realistic time horizon. Failure against an unlimited-resource hypothetical does not prove that a viable niche business is only a feature.", "calibration": "Use a plausible funded competitor response and a realistic time horizon. Failure against an unlimited-resource hypothetical does not prove that a viable niche business is only a feature.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:41" ], "sourceComponents": "Copy Scenario (the largest, best-resourced competitor replicates your core offering), User Retention Analysis (would users stay, and why specifically?), Moat Identification (what exactly prevents defection — data, community, workflow lock-in, specialization, relationships?), Vulnerability Assessment (how long before the copy erodes your advantage?)", "sourceProcedure": "(1) Imagine the worst case: the strongest possible competitor copies your product with unlimited resources → (2) Honestly assess: would your users stay? → (3) If no: you are building a feature, not a business — pivot to moat building immediately → (4) If yes: identify the specific reasons (data advantage? community? workflow lock-in? trust?) → (5) Double down investment on those specific retention factors → (6) Re-run this test quarterly as the competitive landscape shifts", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:41" ] }, { "@id": "urn:business-engineer:model:0042", "@type": "Model", "id": 42, "stableId": "BE-M0042", "name": "Three Layers of AI Industry", "definition": "Separate functional layers of an AI industry to locate dependencies, economics and value capture; layer boundaries depend on the question.", "keyQuestion": "Which layer of the AI industry am I competing in — and do I have the right assets for that layer's competitive dynamics?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which layer of the AI industry am I competing in — and do I have the right assets for that layer's competitive dynamics?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The three-layer map is a high-level lens, not an exhaustive AI stack. Locate cross-layer positions and use more granular layers when infrastructure, orchestration or governance matters.", "calibration": "The three-layer map is a high-level lens, not an exhaustive AI stack. Locate cross-layer positions and use more granular layers when infrastructure, orchestration or governance matters.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:42" ], "sourceComponents": "Foundational Layer (general AI engines — competition is on model capability, capital intensity is extreme), Middle Layer (vertical AI specialization — competition is on domain data and expertise), Application Layer (user-facing products — competition is on UX, network effects, distribution, brand)", "sourceProcedure": "(1) Identify which layer your company competes in → (2) Assess: are you optimally positioned for that layer's competitive dynamics? → (3) Foundational: do you have the capital and talent for model development? → Middle: do you have deep domain data and expertise? → Application: do you have superior UX, distribution, or network effects? → (4) If stuck between layers (no clear advantage at any), either commit to one layer or find a unique cross-layer position → (5) Monitor layer dynamics: foundational is consolidating, middle is fragmenting, application is where network effects matter most", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:control-plane" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:42" ] }, { "@id": "urn:business-engineer:model:0043", "@type": "Model", "id": 43, "stableId": "BE-M0043", "name": "Tech Moat → Market Power Translation", "definition": "A technical advantage becomes market power only through mechanisms such as distribution, switching costs, scarcity or institutional control.", "keyQuestion": "Is my technical advantage actually translating into market power — or is it just technically impressive?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02", "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my technical advantage actually translating into market power — or is it just technically impressive?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:43" ], "sourceComponents": "Technical Capability (the raw technological advantage), Efficiency Channel (does the tech make operations faster, cheaper, or more scalable?), Distribution Channel (does the tech enable superior reach, access, or discovery?), Brand Channel (does the tech create a perception of quality, innovation, or trust?), Market Power (the resulting competitive position from successful translation)", "sourceProcedure": "(1) Inventory your technical capabilities → (2) For each, test the three translation channels: does this tech make us more efficient? Does it improve distribution? Does it enhance brand perception? → (3) If a capability doesn't translate through any channel, it is intellectually interesting but commercially irrelevant → (4) Invest in the channel that provides the strongest translation → (5) The goal is not the best technology but the best translation of technology into market power", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:rent", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:43" ] }, { "@id": "urn:business-engineer:model:0044", "@type": "Model", "id": 44, "stableId": "BE-M0044", "name": "Value Translation Space", "definition": "Identify the gap between a capability and a customer outcome, then determine what integration or business design translates one into the other.", "keyQuestion": "Through which dimensions is my technology actually creating market value — and which dimensions am I neglecting?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Through which dimensions is my technology actually creating market value — and which dimensions am I neglecting?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:44" ], "sourceComponents": "User Experience (intuitive, delightful, friction-free interaction with the technology), Network Effects (each additional user increases value for all existing users), Brand (the market's perception of quality, trust, and identity associated with the product), Distribution Power (the ability to reach, acquire, and retain users efficiently)", "sourceProcedure": "(1) Assess your technical moat: what is the underlying technology advantage? → (2) Map across all four value translation dimensions: where is the tech creating value? → (3) Identify the strongest dimension — lean into it → (4) Identify the weakest dimension — fix it or accept the limitation → (5) The most successful companies have at least two strong value translation dimensions → (6) If none are strong, the technical moat will be commoditized regardless of its sophistication", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:44" ] }, { "@id": "urn:business-engineer:model:0045", "@type": "Model", "id": 45, "stableId": "BE-M0045", "name": "Three AI Strategic Archetypes", "definition": "Compare AI strategic positions by the resources, control and economics their chosen role requires; archetypes can overlap or change.", "keyQuestion": "Am I a Full-Stack Integrator, a Specialized Dominator, or a Strategic Enabler — and is my resource allocation aligned with that choice?", "form": "archetype", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I a Full-Stack Integrator, a Specialized Dominator, or a Strategic Enabler — and is my resource allocation aligned with that choice?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Archetypes describe strategic emphasis. Firms may combine roles when complementary assets and resources support it; forced exclusivity can obscure a viable position.", "calibration": "Archetypes describe strategic emphasis. Firms may combine roles when complementary assets and resources support it; forced exclusivity can obscure a viable position.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:45" ], "sourceComponents": "Full-Stack Integrators (control model + product + distribution — highest capital requirement, highest potential market power), Specialized Dominators (own a vertical with deep data + expertise — moderate capital, high defensibility in niche), Strategic Enablers (provide infrastructure/tools for others — lower risk, recurring revenue, dependent on ecosystem health)", "sourceProcedure": "(1) Assess your resources, capabilities, and ambition → (2) Full-Stack requires enormous capital, talent, and distribution — only viable for well-funded entities → (3) Specialized Dominator requires deep domain expertise and proprietary data — best for vertical experts → (4) Strategic Enabler requires platform thinking and ecosystem cultivation — best for infrastructure builders → (5) Choose one archetype and align all resources → (6) The danger zone is between archetypes — committed to none, optimized for none", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:45" ] }, { "@id": "urn:business-engineer:model:0046", "@type": "Model", "id": 46, "stableId": "BE-M0046", "name": "Weak Spot Analysis (5 Attack Vectors)", "definition": "Identify a rival's consequential weakness and test whether exploiting it is feasible, valuable and defensible.", "keyQuestion": "Through which attack vector is this incumbent most vulnerable — and where do I have the strongest advantage to exploit it?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Through which attack vector is this incumbent most vulnerable — and where do I have the strongest advantage to exploit it?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:46" ], "sourceComponents": "Low-End Disruption (simpler, cheaper for the overserved), Business Model Innovation (different economic model for the same market), New Tech Platform (technology shift that resets advantages), Niche Focus (serve one segment better than any generalist can), Adjacent Market Entry (enter from a neighboring market with existing credibility)", "sourceProcedure": "(1) Select the incumbent you want to challenge → (2) Evaluate all five vectors: where is the incumbent weakest? → (3) Low-end: are they over-serving and over-charging the bottom of the market? → (4) Business model: could a different margin structure undercut them? → (5) New platform: is a technology shift resetting their advantages? → (6) Niche focus: is there a segment they ignore or underserve? → (7) Adjacent entry: can you enter from a market where you're already strong? → (8) Choose the vector where you have the strongest structural advantage", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:46" ] }, { "@id": "urn:business-engineer:model:0047", "@type": "Model", "id": 47, "stableId": "BE-M0047", "name": "Margin Conflict Strategy", "definition": "An incumbent may hesitate to adopt an approach that undermines its existing margin structure; test whether adaptation or segmentation resolves the conflict.", "keyQuestion": "Can I design a model that's profitable at margins the incumbent can't match without cannibalizing themselves?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Can I design a model that's profitable at margins the incumbent can't match without cannibalizing themselves?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:47", "base:70" ], "sourceComponents": "Incumbent Margin Analysis (what margins does the competitor need to satisfy their stakeholders?), Alternative Margin Design (how can you build a profitable model at lower/different margins?), Cannibalization Dilemma (responding means destroying their own margins), Response Delay (the internal conflict that slows incumbent adaptation)", "sourceProcedure": "(1) Analyze the incumbent's margin structure: what do they charge and why? → (2) Design a model that is profitable at a margin structure the incumbent cannot match without cannibalization → (3) Enter the market: the incumbent now faces a dilemma — respond and erode margins, or ignore and lose share → (4) The internal conflict (sales teams resist margin cuts, boards resist revenue decline) creates a response delay → (5) Use that delay to build your moat → (6) By the time they respond, you should have a structural advantage", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:47", "urn:business-engineer:source-entry:base:70" ] }, { "@id": "urn:business-engineer:model:0048", "@type": "Model", "id": 48, "stableId": "BE-M0048", "name": "Strategic Mismatch Model", "definition": "Look for a mismatch between an organization's strategy, capabilities, incentives and changing market requirements.", "keyQuestion": "Do I see something in the data that the incumbent's lens structurally prevents them from seeing?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Do I see something in the data that the incumbent's lens structurally prevents them from seeing?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Interpretation can matter, but superior data, execution and resources can also decide outcomes. Treat perspective advantage as one mechanism to test.", "calibration": "Interpretation can matter, but superior data, execution and resources can also decide outcomes. Treat perspective advantage as one mechanism to test.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:48" ], "sourceComponents": "Incumbent Lens (how does the established player interpret market signals?), Disruptor Lens (what different interpretation framework reveals unseen opportunities?), Interpretation Gap (the delta between what both see in the same data), Structural Blindness (what the incumbent's lens systematically prevents them from seeing)", "sourceProcedure": "(1) Map the incumbent's interpretive lens: what do they optimize for? How do they measure success? → (2) Identify their structural blindness: what does their lens systematically filter out? → (3) Develop an alternative interpretation: using the same data, what do you see that they can't? → (4) Build your strategy around the interpretation gap → (5) The incumbent may have more data, more resources, and more talent — but if your interpretation is more accurate, you will outmaneuver them → (6) The mismatch persists as long as the incumbent's incentives keep their lens locked", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:48" ] }, { "@id": "urn:business-engineer:model:0049", "@type": "Model", "id": 49, "stableId": "BE-M0049", "name": "Non-Linear Competition", "definition": "Competition can change discontinuously when technology, distribution or business-model shifts alter the basis of advantage.", "keyQuestion": "Do I have an asymmetric advantage that could compound non-linearly — and am I investing to reach the cascade threshold?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Do I have an asymmetric advantage that could compound non-linearly — and am I investing to reach the cascade threshold?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:49" ], "sourceComponents": "Asymmetric Advantage Identification (where do you have a small advantage with compounding potential?), Threshold Detection (at what point does the advantage cascade into dominance?), Non-Linear Sensitivity (small changes in input can produce large changes in outcome), Incumbent Blind Spot (linear thinkers underestimate non-linear competitors)", "sourceProcedure": "(1) Identify your asymmetric advantages — areas where you have even a small edge → (2) Assess compounding potential: does this advantage grow with each iteration, user, or transaction? → (3) Estimate the threshold: at what point does incremental growth become a cascade? → (4) Invest to reach the threshold before competitors recognize the threat → (5) Defend the compounding mechanism once the cascade begins → (6) Do not expect competitors to see this coming — linear thinkers systematically underestimate non-linear dynamics", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:49" ] }, { "@id": "urn:business-engineer:model:0050", "@type": "Model", "id": 50, "stableId": "BE-M0050", "name": "Winner-Take-All Effects", "definition": "Positive feedback and market structure may concentrate outcomes; congestion, differentiation, multi-homing and regulation can limit concentration.", "keyQuestion": "Is this a winner-take-all market — and if so, am I positioned to win or do I need to redefine the game?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this a winner-take-all market — and if so, am I positioned to win or do I need to redefine the game?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Test winner-take-most versus winner-take-all conditions, including multi-homing, differentiation, congestion, regulation and declining returns. Second place can remain profitable.", "calibration": "Test winner-take-most versus winner-take-all conditions, including multi-homing, differentiation, congestion, regulation and declining returns. Second place can remain profitable.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:50" ], "sourceComponents": "Network Effect Strength (how much does each user increase value for others?), Switching Cost Height (how difficult is it for users to leave?), Data Returns to Scale (does more data create proportionally better products?), Consolidation Trajectory (is the market converging toward one winner or remaining fragmented?), Strategic Implication (if WTA, either win or redefine the layer)", "sourceProcedure": "(1) Assess the market for WTA conditions: strong network effects? High switching costs? Data returns to scale? → (2) If all three are present, this is a WTA market — half measures will fail → (3) If you're the leader: invest aggressively to widen the gap → (4) If you're not the leader: either find a way to leapfrog (technology shift, redefine the layer) or exit → (5) If WTA conditions are weak, the market supports multiple players — compete on differentiation → (6) Monitor: WTA conditions can emerge or dissolve as technology and regulation evolve", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:50" ] }, { "@id": "urn:business-engineer:model:0051", "@type": "Model", "id": 51, "stableId": "BE-M0051", "name": "Agentic AI Four-Phase Moat Building", "definition": "Analyze how agentic AI defensibility changes as capabilities and adoption develop; phase labels are a scenario framework, not a fixed chronology.", "keyQuestion": "Which phase am I actually in — and am I doing the work required at this phase before trying to jump ahead?", "form": "framework", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which phase am I actually in — and am I doing the work required at this phase before trying to jump ahead?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The four phases are a planning heuristic, not a required historical sequence. Phases can overlap or reverse and should be diagnosed from evidence.", "calibration": "The four phases are a planning heuristic, not a required historical sequence. Phases can overlap or reverse and should be diagnosed from evidence.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:51" ], "sourceComponents": "Foundation Phase (core agentic capabilities, reliability, basic trust), Differentiation Phase (unique capabilities, proprietary data, specialized workflows), Dominance Phase (self-reinforcing flywheels, compounding advantage), Expansion Phase (adjacent domain entry, moat extension, ecosystem building)", "sourceProcedure": "(1) Honestly assess: which phase are you in? Most overestimate → (2) Foundation: focus on reliability, speed, and basic trust — do not differentiate yet → (3) Differentiation: invest in what makes you unique — proprietary data, specialized capabilities, unique workflows → (4) Dominance: design systems so usage compounds advantage — data flywheels, network effects, workflow lock-in → (5) Expansion: once the flywheel spins, extend into adjacent domains → (6) Do not skip phases — the foundation must hold the weight of everything built above it", "usesConcept": [ "urn:business-engineer:concept:permission" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:51" ] }, { "@id": "urn:business-engineer:model:0052", "@type": "Model", "id": 52, "stableId": "BE-M0052", "name": "Three Kingdoms of Agentic AI", "definition": "Map distinct agentic AI strategic arenas and their control points; boundaries and winners remain empirical questions.", "keyQuestion": "Am I in the Consumer, B2B, or Enterprise kingdom — and does my strategy match that kingdom's rules?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I in the Consumer, B2B, or Enterprise kingdom — and does my strategy match that kingdom's rules?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:52" ], "sourceComponents": "Consumer Kingdom (attention-based competition, habit/network moats, engagement metrics, viral distribution), B2B Kingdom (ROI-based competition, workflow/outcome moats, value metrics, sales-driven distribution), Enterprise Kingdom (trust-based competition, compliance/relationship moats, contract metrics, relationship-driven distribution)", "sourceProcedure": "(1) Identify which kingdom you are competing in — the rules differ fundamentally → (2) Consumer: invest in habit formation, viral loops, and attention capture → (3) B2B: invest in measurable ROI, workflow integration, and customer success → (4) Enterprise: invest in security, compliance, trust, and deep relationships → (5) Do not apply Consumer strategies in Enterprise (it signals naivety) or Enterprise strategies in Consumer (it kills speed) → (6) Some companies span kingdoms — but each kingdom needs its own approach", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:52" ] }, { "@id": "urn:business-engineer:model:0053", "@type": "Model", "id": 53, "stableId": "BE-M0053", "name": "Context Engineering", "definition": "Engineer the information, tools, memory and instructions available to a system so that they support a defined task and reliable behavior.", "keyQuestion": "Am I engineering the context my AI operates in — or just throwing information at it and hoping?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I engineering the context my AI operates in — or just throwing information at it and hoping?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:53" ], "sourceComponents": "Context Orchestration (selecting which information to include from available sources), Context Structuring (organizing information for optimal model processing), Context Prioritization (ordering information by relevance and importance), Context Maintenance (updating context as conditions change), Performance Measurement (tracking how context changes affect output quality)", "sourceProcedure": "(1) Map all available context sources for a given AI application → (2) Select: which information is most relevant and useful for the intended task? → (3) Structure: organize the selected information for optimal model comprehension → (4) Prioritize: order by relevance — most important context first → (5) Test: measure output quality with different context configurations → (6) Iterate: continuously refine context architecture based on performance data → (7) Remember: context engineering compounds — better context → better outputs → better data → better context", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:53" ] }, { "@id": "urn:business-engineer:model:0054", "@type": "Model", "id": 54, "stableId": "BE-M0054", "name": "Protocol Mastery", "definition": "Use protocols to improve coordination and interoperability while separating adoption, permission, portability and actual market control.", "keyQuestion": "Am I building deep protocol mastery that creates ecosystem lock-in — or treating protocols as commodity infrastructure?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D07" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I building deep protocol mastery that creates ecosystem lock-in — or treating protocols as commodity infrastructure?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Open-protocol adoption enables interoperability but does not by itself establish lock-in or a moat. Verify scarce complements, ecosystem participation, governance, switching costs and demonstrated value; protocol availability is separate from business authorization.", "calibration": "Open-protocol adoption enables interoperability but does not by itself establish lock-in or a moat. Verify scarce complements, ecosystem participation, governance, switching costs and demonstrated value; protocol availability is separate from business authorization.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:54" ], "sourceComponents": "Protocol Identification (which emerging standards will define AI interoperability?), Deep Implementation (not just adopting but mastering the protocol's capabilities and edge cases), Ecosystem Network Effects (each integration increases the value of your protocol mastery), Technical Barriers (protocol expertise creates switching costs for partners and customers), Standards Influence (contributing to protocol development shapes the rules in your favor)", "sourceProcedure": "(1) Identify the most consequential emerging AI protocols → (2) Invest in deep implementation — not surface adoption but mastery of capabilities and edge cases → (3) Build integrations that leverage protocol capabilities others haven't discovered → (4) Create ecosystem value: help partners implement the protocol, creating network effects around your expertise → (5) Contribute to protocol development to influence the standards → (6) The moat: as the ecosystem builds around your protocol mastery, switching costs compound", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:control-plane" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:54" ] }, { "@id": "urn:business-engineer:model:0055", "@type": "Model", "id": 55, "stableId": "BE-M0055", "name": "Agentic Competitive Formula", "definition": "Assess agentic competitiveness through complementary capabilities, integration, distribution and trust; illustrative formulas require measurement before calculation.", "keyQuestion": "Which factor in my competitive formula is closest to zero — and is that the one I'm investing in?", "form": "framework", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which factor in my competitive formula is closest to zero — and is that the one I'm investing in?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The multiplicative formula is a qualitative checklist, not a predictive equation. Network effects are not necessary for every successful business, and multiplying invented factor scores creates false precision.", "calibration": "The multiplicative formula is a qualitative checklist, not a predictive equation. Network effects are not necessary for every successful business, and multiplying invented factor scores creates false precision.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:55" ], "sourceComponents": "Market Focus (are you solving a specific, urgent problem for a defined audience?), Technical Excellence (is your technology genuinely superior in the ways that matter for that market?), Network Effects (does usage create compounding advantage?), Time (are you giving the compounding enough time to work?)", "sourceProcedure": "(1) Rate each factor honestly from 0 to 10 → (2) Multiply: if any factor is near zero, the product is near zero — fix that factor first → (3) Market Focus: narrow until you have a clearly defined audience with an urgent problem → (4) Technical Excellence: ensure superiority on the dimensions that matter to your market → (5) Network Effects: design for compounding — usage must improve the product → (6) Time: commit to the timeline required for compounding — impatience kills agentic businesses → (7) Balance all four — strength in three with zero in one is still zero", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:55" ] }, { "@id": "urn:business-engineer:model:0056", "@type": "Model", "id": 56, "stableId": "BE-M0056", "name": "AI-Up (AI-Native Startup)", "definition": "Redesign a workflow around feasible AI capabilities, its required outcomes and human responsibilities rather than adding automation without process change.", "keyQuestion": "Am I building an AI-native organization that can build defensible value before incumbents can respond — or a traditional startup using AI as a feature?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I building an AI-native organization that can build defensible value before incumbents can respond — or a traditional startup using AI as a feature?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:56" ], "sourceComponents": "AI-Native Operations (AI embedded in every function, not just the product), Speed Advantage (iteration cycles measured in hours/days, not weeks/months), Lean Team (small team with AI augmentation achieving enterprise-level output), Response Gap (the time between AI-Up's market entry and incumbent's organized response), Value Window (the period during which the AI-Up can build defensible value)", "sourceProcedure": "(1) Build every function — development, marketing, sales, support, analytics — with AI augmentation from day one → (2) Optimize for iteration speed: the AI-Up's primary advantage is speed of learning → (3) Maintain lean team size: AI augmentation should substitute for headcount → (4) Target the response gap: enter markets where incumbent response will be slow → (5) Build defensible value (moats, customers, data) before the response gap closes → (6) Never let organizational complexity outpace AI-augmented capacity", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:56" ] }, { "@id": "urn:business-engineer:model:0057", "@type": "Model", "id": 57, "stableId": "BE-M0057", "name": "Platform Network Ecosystem", "definition": "Distinguish a platform's interfaces, a network's participants and an ecosystem's complementary relationships to explain value creation and capture.", "keyQuestion": "Does my platform enable more value than it extracts — and are network effects compounding across all sides?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my platform enable more value than it extracts — and are network effects compounding across all sides?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:57" ], "sourceComponents": "Multi-Sided Market Design (what sides exist — producers, consumers, developers, advertisers?), Network Effect Cultivation (how does each side's growth attract the other sides?), Platform Governance (rules for quality, behavior, and value distribution), Control-Value Balance (how much does the platform extract vs. enable?), Ecosystem Health Metrics (participation growth, value creation, satisfaction across all sides)", "sourceProcedure": "(1) Define the sides of your market: who creates value, who consumes it, who enables it? → (2) Identify the chicken-and-egg problem: which side needs to be seeded first? → (3) Design for network effects: each participant's value must increase as others join → (4) Establish governance: rules that maintain quality without strangling participation → (5) Monitor the control-value balance: if participants feel extracted from rather than enabled, the ecosystem will decay → (6) Measure ecosystem health, not just platform revenue", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:57" ] }, { "@id": "urn:business-engineer:model:0058", "@type": "Model", "id": 58, "stableId": "BE-M0058", "name": "Agentic Web Architecture", "definition": "Map how agents discover, interpret, coordinate and act through web infrastructure, including the authority and controls at each interface.", "keyQuestion": "Which layer of the agentic web architecture can I contribute to or build on — and am I positioning for the emerging infrastructure?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which layer of the agentic web architecture can I contribute to or build on — and am I positioning for the emerging infrastructure?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Treat the architecture as a conceptual scenario. Current protocol support, agent autonomy and adoption require verification; do not describe an envisioned autonomous economy as an established state.", "calibration": "Treat the architecture as a conceptual scenario. Current protocol support, agent autonomy and adoption require verification; do not describe an envisioned autonomous economy as an established state.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:58" ], "sourceComponents": "Agent Mesh Networks (discovery, communication, and collaboration protocols between AI agents), Decision Protocols (frameworks for autonomous agent decision-making and coordination), Resource Allocation Systems (how agents manage and distribute compute, data, and financial resources), Autonomous Economic Systems (agent-to-agent transactions, value creation, and economic coordination)", "sourceProcedure": "(1) Map the current state of agentic web infrastructure: which layers are emerging? → (2) Identify which layer your company can contribute to or build on → (3) Agent Mesh: build or participate in agent discovery and communication networks → (4) Decision Protocols: develop or adopt frameworks for agent coordination → (5) Resource Allocation: create systems for efficient agent resource management → (6) Economic Systems: design mechanisms for agent-to-agent value exchange → (7) Position early: the architecture is being built now, and early participants will shape the standards", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:autonomy-envelope" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:58" ] }, { "@id": "urn:business-engineer:model:0059", "@type": "Model", "id": 59, "stableId": "BE-M0059", "name": "Amazon Flywheel", "definition": "Analyze the reinforcing links in Amazon's historical flywheel as a case-derived hypothesis; verify current company facts separately.", "keyQuestion": "Does my business have a flywheel where each element reinforces the others — or am I manually pushing growth at every step?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my business have a flywheel where each element reinforces the others — or am I manually pushing growth at every step?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "A reinforcing loop still has weak links, congestion and competitive responses. Growth is not automatic and competing against parts of the system is not structurally impossible.", "calibration": "A reinforcing loop still has weak links, congestion and competitive responses. Growth is not automatic and competing against parts of the system is not structurally impossible.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:59" ], "sourceComponents": "Lower Prices (attracts price-sensitive customers and increases volume), More Customers (attracts sellers and increases bargaining power), More Sellers (increases selection and competition), Greater Selection (improves customer experience), Lower Costs (scale and competition drive efficiency), Reinforcement Loop (each element strengthens every other)", "sourceProcedure": "(1) Study the Amazon flywheel not to copy it but to understand the principle: every element must reinforce every other → (2) Map your own business: what is the equivalent of \"lower prices\" — the entry point that attracts the first side? → (3) Identify the reinforcement path: does growth in one area automatically feed growth in another? → (4) Find the weak link: which connection in your flywheel is weakest? → (5) Invest in strengthening the weak link — the flywheel is only as strong as its weakest connection → (6) Test: does the system compound — or does it require constant external input to keep spinning?", "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:59" ] }, { "@id": "urn:business-engineer:model:0060", "@type": "Model", "id": 60, "stableId": "BE-M0060", "name": "Data Flywheel", "definition": "Data improves an outcome only if a repeatable learning process converts new observations into better performance and renewed data generation.", "keyQuestion": "Is my data flywheel spinning — and is the gap between me and competitors widening or narrowing with each revolution?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03", "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my data flywheel spinning — and is the gap between me and competitors widening or narrowing with each revolution?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Additional data helps only when it is usable, relevant, sufficiently differentiated and improves outcomes economically. Rights, quality, diminishing returns, synthetic substitutes and feedback quality matter. A data collection loop is not automatically a data network effect.", "calibration": "Additional data helps only when it is usable, relevant, sufficiently differentiated and improves outcomes economically. Rights, quality, diminishing returns, synthetic substitutes and feedback quality matter. A data collection loop is not automatically a data network effect.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:60" ], "sourceComponents": "Usage (users interacting with the product generate data), Data Accumulation (interactions create proprietary training and behavioral data), Model Improvement (more/better data improves model accuracy, speed, and relevance), Product Enhancement (better models create better user experience), Usage Growth (better product attracts more users, generating more data)", "sourceProcedure": "(1) Map your data flywheel: what data does each user interaction generate? → (2) Assess data quality: is the data generated actually useful for model improvement? → (3) Measure flywheel speed: how quickly does new data translate into product improvement? → (4) Identify bottlenecks: is usage, data quality, model training, or product deployment the constraint? → (5) Accelerate the bottleneck → (6) Measure the gap: how far ahead is your data flywheel compared to competitors? → (7) The wider the gap, the more defensible your position", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:60" ] }, { "@id": "urn:business-engineer:model:0061", "@type": "Model", "id": 61, "stableId": "BE-M0061", "name": "Content Flywheel", "definition": "Useful content can attract an audience whose feedback and distribution improve subsequent content; test attention quality, conversion and production cost.", "keyQuestion": "Does my audience growth itself improve my content quality and distribution — or is this just a linear production process?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my audience growth itself improve my content quality and distribution — or is this just a linear production process?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:61" ], "sourceComponents": "Content Creation (producing valuable, original content), Distribution (reaching audiences through platforms, algorithms, direct channels), Audience Building (growing an engaged, loyal audience), Monetization (converting audience attention into revenue), Reinvestment (channeling revenue back into content quality and distribution)", "sourceProcedure": "(1) Start with creation: what content can you produce that provides genuine value? → (2) Distribute through the most effective channels for your audience → (3) Build audience with a focus on engagement, not just reach → (4) Monetize in a way that preserves audience trust → (5) Reinvest in creation quality and distribution expansion → (6) The critical question: does your audience itself improve your content? (through feedback, UGC, signal data) → (7) If yes, the flywheel is real; if no, you have a production line that requires constant manual input", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:61" ] }, { "@id": "urn:business-engineer:model:0062", "@type": "Model", "id": 62, "stableId": "BE-M0062", "name": "Traction-Momentum-Flywheel", "definition": "Distinguish initial traction, repeatable momentum and a reinforcing growth loop; growth alone does not prove a flywheel.", "keyQuestion": "Am I in the Traction, Momentum, or Flywheel phase — and am I doing the right work for that phase?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I in the Traction, Momentum, or Flywheel phase — and am I doing the right work for that phase?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:62" ], "sourceComponents": "Traction Phase (proving value, finding PMF, initial revenue/engagement, small-group validation), Momentum Phase (scaling proven model, team growth, channel expansion, market share gains), Flywheel Phase (self-reinforcing growth, compounding advantage, decreasing marginal investment per growth increment)", "sourceProcedure": "(1) Honestly assess: which phase are you in? Most overestimate → (2) Traction: focus exclusively on proving value for the smallest possible audience — nothing else matters → (3) Momentum: once value is proven, invest in scaling — team, channels, operations → (4) Flywheel: design systems where growth reinforces itself without proportional investment → (5) The transition between phases is the most dangerous moment — premature scaling kills more businesses than competition → (6) Look for phase indicators: Traction = consistent repeat usage; Momentum = growth rate increasing; Flywheel = growth continues even when investment pauses", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:62" ] }, { "@id": "urn:business-engineer:model:0063", "@type": "Model", "id": 63, "stableId": "BE-M0063", "name": "Innovation Flywheel", "definition": "Innovation can reinforce adoption, complementary investment and further innovation when each link has a viable incentive and resource path.", "keyQuestion": "Is my innovation flywheel compounding — does each breakthrough build on the last and fund the next?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my innovation flywheel compounding — does each breakthrough build on the last and fund the next?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:63" ], "sourceComponents": "R&D Investment (allocated resources for research and development), Breakthrough Generation (novel discoveries, inventions, or capabilities), Market Advantage Conversion (turning breakthroughs into products, services, or competitive positions), Revenue Generation (income from the market advantage), Reinvestment (channeling revenue back to R&D), Cumulative Knowledge (each cycle builds on everything learned before)", "sourceProcedure": "(1) Establish the initial investment: allocate meaningful resources to R&D → (2) Focus on breakthrough potential, not incremental improvement → (3) Build fast conversion capability: reduce time from breakthrough to market advantage → (4) Ensure the market advantage generates sufficient revenue to fund the next cycle → (5) Reinvest with discipline: the ratio of reinvestment determines flywheel speed → (6) Cultivate cumulative knowledge: ensure each breakthrough builds on previous ones, compounding the advantage → (7) The flywheel stalls when reinvestment drops or when breakthroughs stop building on each other", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:63" ] }, { "@id": "urn:business-engineer:model:0064", "@type": "Model", "id": 64, "stableId": "BE-M0064", "name": "AI Priming-Proving Flywheel", "definition": "Use AI to prepare and test possibilities, then feed verified results into subsequent work; distinguish generated plausibility from observed proof.", "keyQuestion": "Am I actively watching for emergent use cases that my AI capabilities are priming — or only measuring the use cases I planned for?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I actively watching for emergent use cases that my AI capabilities are priming — or only measuring the use cases I planned for?", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:64" ], "sourceComponents": "Capability Priming (AI capabilities reveal new, unexpected use cases), Value Proving (successful use cases demonstrate measurable value), Demand Generation (proven value creates demand for additional AI capability), Investment Attraction (demand justifies further AI development investment), Capability Expansion (investment creates new capabilities that prime further use cases)", "sourceProcedure": "(1) Deploy AI capability and actively watch for unexpected use cases — users will find applications you didn't design for → (2) When unexpected use cases emerge, validate and measure the value created → (3) Use proven value to generate demand: \"This worked here — imagine what it could do there\" → (4) Channel demand into investment in expanded capabilities → (5) New capabilities prime the next cycle of use case discovery → (6) Accelerate the loop by deliberately exposing AI to diverse contexts to maximize priming → (7) The flywheel stalls if you only deploy for planned use cases and ignore emergent ones", "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:64" ] }, { "@id": "urn:business-engineer:model:0065", "@type": "Model", "id": 65, "stableId": "BE-M0065", "name": "Asymmetric Business Unit Model", "definition": "Use a business unit with a different risk, margin or time profile to create options for the wider firm while making subsidies and dependencies visible.", "keyQuestion": "Do I have a high-margin unit that can structurally subsidize a low-margin unit to create an unassailable combined position?", "form": "archetype", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Do I have a high-margin unit that can structurally subsidize a low-margin unit to create an unassailable combined position?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Cross-subsidy requires evidence of cash allocation and causal interaction between units. Do not assume that a profitable cloud segment literally funds a particular retail price reduction without support.", "calibration": "Cross-subsidy requires evidence of cash allocation and causal interaction between units. Do not assume that a profitable cloud segment literally funds a particular retail price reduction without support.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:65" ], "sourceComponents": "Subsidy Unit (high-margin business generating surplus cash flow), Scale Unit (low-margin business using the subsidy to achieve unbeatable competitive position), Cross-Subsidy Mechanism (how cash flows from one unit to the other), Competitive Moat (the combined position is impossible to attack from either side — a competitor cannot match the low margins without the high-margin unit, and cannot build the high-margin unit without the scale unit's market position)", "sourceProcedure": "(1) Identify your high-margin unit: which part of the business generates surplus cash flow? → (2) Identify or design a low-margin unit that can use that subsidy to build unassailable market position → (3) Establish the cross-subsidy mechanism: how does cash flow from the subsidy unit to the scale unit? → (4) Verify the competitive moat: can a competitor attack either unit independently? → (5) If the moat holds, invest aggressively — the asymmetric structure is itself a compounding advantage → (6) Monitor for risk: if the high-margin unit's profitability declines, the entire structure is threatened", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:65" ] }, { "@id": "urn:business-engineer:model:0066", "@type": "Model", "id": 66, "stableId": "BE-M0066", "name": "VTDF Framework", "definition": "Analyze a business through value, technology, distribution and financial dimensions and the tradeoffs connecting them.", "keyQuestion": "Across Value, Technology, Distribution, and Financial — where is my business model strongest, weakest, and most vulnerable to disruption?", "form": "framework", "domains": [ "urn:business-engineer:domain:D02", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Across Value, Technology, Distribution, and Financial — where is my business model strongest, weakest, and most vulnerable to disruption?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:66" ], "sourceComponents": "Value Model (what problem is solved, for whom, with what unique approach?), Technology Model (what technology enables this, and how does it create advantage?), Distribution Model (how do you reach, acquire, and retain users?), Financial Model (how do you generate revenue, manage costs, and create sustainable margins?)", "sourceProcedure": "(1) Map any business across all four dimensions → (2) Assess the connections: does the technology enable the value proposition? Does the distribution reach the right audience? Does the financial model sustain the operation? → (3) Identify the weakest dimension: that's the bottleneck → (4) Test for innovation potential: a shift in any one dimension forces re-evaluation of the other three → (5) When analyzing competitors, map their VTDF and look for dimensions they are neglecting → (6) Build your strategy around strength in at least two dimensions and adequacy in the other two", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:66" ], "modes": [ "urn:business-engineer:mode:strategic" ] }, { "@id": "urn:business-engineer:model:0067", "@type": "Model", "id": 67, "stableId": "BE-M0067", "name": "Catalyst Quadrant: Defend, Attack, Transform, Create", "aliases": [ "Catalyst Quadrant (DATC)" ], "definition": "Allocate attention and resources among Defend, Attack, Transform and Create according to the firm's circumstances; review tradeoffs without assuming all four require fixed positive budgets.", "keyQuestion": "Am I operating in all four modes simultaneously — or am I stuck in only Defend or only Attack?", "form": "framework", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I operating in all four modes simultaneously — or am I stuck in only Defend or only Attack?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Defend, Attack, Transform and Create are useful modes. Operating all four at once is not mandatory when resources or the strategic situation support focused allocation.", "calibration": "Defend, Attack, Transform and Create are useful modes. Operating all four at once is not mandatory when resources or the strategic situation support focused allocation.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:67" ], "sourceComponents": "Defend Mode (protect current revenue, strengthen existing moats, repel competitive threats), Attack Mode (exploit competitor weaknesses, capture market share, aggressive positioning), Transform Mode (evolve business model, build new capabilities, prepare for market shifts), Create Mode (build entirely new offerings, enter new markets, innovate from scratch)", "sourceProcedure": "(1) Assess your current environment: which mode is most urgent? → (2) But do not only operate in the most urgent mode — all four must run simultaneously → (3) Allocate resources: in a crisis, Defend may get 40%; in a growth phase, Attack or Create may dominate → (4) Ensure Transform never goes to zero — organizations that only Defend/Attack without Transforming are optimizing for a world that's disappearing → (5) Ensure Create never goes to zero — organizations that only Transform without Creating become consultants, not builders → (6) Review quadrant allocation quarterly", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:67" ] }, { "@id": "urn:business-engineer:model:0068", "@type": "Model", "id": 68, "stableId": "BE-M0068", "name": "Transitional vs Foundational Technology", "definition": "Distinguish a temporary enabling technology from infrastructure that supports many complementary applications, allowing the classification to change with evidence.", "keyQuestion": "Which technology layer am I operating on — and does my strategy match the time horizon and dynamics of that layer?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which technology layer am I operating on — and does my strategy match the time horizon and dynamics of that layer?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The lifespan bands are illustrative, not empirical clocks. A technology can operate at several layers and persist or be displaced on different schedules.", "calibration": "The lifespan bands are illustrative, not empirical clocks. A technology can operate at several layers and persist or be displaced on different schedules.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:68" ], "sourceComponents": "Product Layer (0-1yr: specific tools and features — high turnover, low defensibility), Application Layer (1-5yr: platform-level tools — moderate defensibility, evolving rapidly), Transitional Technology Layer (5-15yr: bridges between paradigms — important but temporary), Foundational Technology Layer (15-30yr: the platforms that reshape industries — high defensibility, long-term value), Supercycle Catalyst Layer (30-50yr: economy-reshaping forces — generational transformation)", "sourceProcedure": "(1) Classify your technology or product: which layer are you operating on? → (2) Product layer: optimize for speed and iteration, expect short lifespan → (3) Application layer: build for broader adoption, invest in UX and ecosystem → (4) Transitional: understand that you are a bridge — build for migration to the foundational layer → (5) Foundational: invest for the long term, build deep moats, expect slow adoption but massive eventual impact → (6) Supercycle: think in decades, position for generational transformation → (7) The strategic error is applying the wrong time horizon to the wrong layer", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:68" ] }, { "@id": "urn:business-engineer:model:0069", "@type": "Model", "id": 69, "stableId": "BE-M0069", "name": "AI Supercycle Three-Phase Model", "definition": "Use AI supercycle phases to organize hypotheses about capability, adoption and economic integration without imposing a universal timetable.", "keyQuestion": "Which phase of the AI supercycle is my industry in — and am I positioned for the next phase?", "form": "framework", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which phase of the AI supercycle is my industry in — and am I positioned for the next phase?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The phases can overlap by sector and geography. Remove the undated claim about where we are currently; establish an as-of date and adoption evidence for any phase assignment.", "calibration": "The phases can overlap by sector and geography. Remove the undated claim about where we are currently; establish an as-of date and adoption evidence for any phase assignment.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:69" ], "sourceComponents": "Phase 1 — AI Eating the Web (web-native businesses disrupted first — search, content, commerce, advertising), Phase 2 — Industry Restructuring (traditional industries transformed — healthcare, finance, manufacturing, education), Phase 3 — AI-Native Economic Models (new economic structures that could not exist without AI — agentic economies, autonomous markets)", "sourceProcedure": "(1) Identify which phase your industry is in → (2) Phase 1 businesses: the disruption is already underway — adapt immediately or be absorbed → (3) Phase 2 industries: prepare now — the restructuring wave is approaching → (4) Phase 3 opportunities: begin exploring AI-native business models that have no pre-AI equivalent → (5) Investment strategy: Phase 1 plays are maturing, Phase 2 plays are emerging, Phase 3 plays are speculative but potentially transformational → (6) The biggest strategic error is assuming your industry won't be affected until Phase 3", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:institution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:69" ] }, { "@id": "urn:business-engineer:model:0071", "@type": "Model", "id": 71, "stableId": "BE-M0071", "name": "Dogfooding Framework", "definition": "Using one's own product can expose operating problems and accelerate feedback, but employees are not necessarily representative customers.", "keyQuestion": "Am I truly using my own product for real work — and are the pain points I'm finding relevant to external customers?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I truly using my own product for real work — and are the pain points I'm finding relevant to external customers?", "evidence": "Define an accepted outcome, baseline and owner; measure total delivery cost, quality, exceptions, attribution and performance after release.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:71" ], "sourceComponents": "Internal Adoption (mandatory use by the building team — not optional, not ceremonial), Pain Recognition (systematic documentation of friction, failures, and gaps discovered through real usage), Solution Validation (internal fixes tested for applicability to external customer problems), External Validation (market launch backed by evidence of real-world usage)", "sourceProcedure": "(1) Require the entire team to use the product daily for real work — not demos, not tests, real work → (2) Create a structured process for documenting every friction point and failure → (3) Prioritize pain points by frequency and severity → (4) Develop solutions and validate: does fixing this internal pain also solve an external customer problem? → (5) If yes, ship it; if no, it may be an internal-only issue — investigate further → (6) Only declare the product ready for market when internal usage is genuinely productive and pain points are resolved → (7) Continue dogfooding post-launch — it never stops", "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:baseline", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:adjudication", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:71" ] }, { "@id": "urn:business-engineer:model:0072", "@type": "Model", "id": 72, "stableId": "BE-M0072", "name": "AI Implementation Pyramid (4-Tier)", "definition": "Sequence AI adoption according to process readiness, capability requirements, risk and economic value rather than a fixed maturity ladder.", "keyQuestion": "Is my AI investment pyramid balanced — or am I over-investing in speculative AI while neglecting guaranteed productivity gains?", "form": "framework", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my AI investment pyramid balanced — or am I over-investing in speculative AI while neglecting guaranteed productivity gains?", "evidence": "Define an accepted outcome, baseline and owner; measure total delivery cost, quality, exceptions, attribution and performance after release.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The 70/15/10/5 budget split is illustrative. Productivity gains are not guaranteed; allocate after testing process fit, adoption, total cost and measurable outcomes.", "calibration": "The 70/15/10/5 budget split is illustrative. Productivity gains are not guaranteed; allocate after testing process fit, adoption, total cost and measurable outcomes.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:72" ], "sourceComponents": "Tier 1 — Productivity Tools (70% allocation: AI for speed, cost reduction, quality in existing workflows), Tier 2 — Workflow Automation (15%: AI replacing entire workflow segments), Tier 3 — Strategic Advantages (10%: AI creating defensible competitive positions), Tier 4 — R&D Bets (5%: speculative AI explorations with transformational potential)", "sourceProcedure": "(1) Audit current AI spending: does it match the pyramid ratio? → (2) Tier 1 should be the bulk: identify the top 10 workflows where AI can immediately improve productivity → (3) Tier 2: select 2-3 workflow segments ripe for full automation → (4) Tier 3: invest in one strategic AI advantage that competitors cannot easily replicate → (5) Tier 4: allocate a small budget for speculative exploration — accept that most Tier 4 bets will fail → (6) Review and rebalance quarterly → (7) Promote successful Tier 4 bets to Tier 3, Tier 3 successes to Tier 2, as maturity increases", "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:baseline", "urn:business-engineer:concept:adjudication", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:72" ] }, { "@id": "urn:business-engineer:model:0073", "@type": "Model", "id": 73, "stableId": "BE-M0073", "name": "Asymmetric Betting Matrix", "definition": "Compare bets by upside, downside, probability, learning value and affordability; asymmetric payoffs do not guarantee favorable expected value.", "keyQuestion": "Is my strategic portfolio balanced across bet sizes — or am I over-concentrated in either high-risk or low-return positions?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D01", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my strategic portfolio balanced across bet sizes — or am I over-concentrated in either high-risk or low-return positions?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The position-size and return ranges are uncalibrated illustrations, not portfolio advice or expected-return estimates. Use actual downside, funding needs, correlation and decision-specific probabilities where defensible.", "calibration": "The position-size and return ranges are uncalibrated illustrations, not portfolio advice or expected-return estimates. Use actual downside, funding needs, correlation and decision-specific probabilities where defensible.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:73" ], "sourceComponents": "Micro Bets (0.1-1% resources, 1000x+ potential — high risk, transformational upside), Small Bets (1-2% resources, 100-1000x potential — speculative but within visibility), Medium Bets (2-5% resources, 10-100x potential — calculated risks with clear thesis), Core Bets (5-10% resources, 3-10x potential — high-conviction, strong evidence)", "sourceProcedure": "(1) Inventory your strategic bets: what are you currently investing in? → (2) Classify each bet by position size and realistic potential return → (3) Ensure portfolio balance: too many core bets = no upside; too many micro bets = no stability → (4) For micro bets: optimize for quantity and speed — make many small bets, kill losers fast → (5) For core bets: optimize for conviction — deep analysis, high confidence → (6) Rebalance regularly: promote winning micro/small bets to medium/core; cut non-performers → (7) The portfolio is the strategy, not any individual bet", "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:73" ] }, { "@id": "urn:business-engineer:model:0075", "@type": "Model", "id": 75, "stableId": "BE-M0075", "name": "Act vs Wait Mental Model", "definition": "Choose between acting and waiting by comparing the value of learning and optionality with the costs of delay and lost opportunities.", "keyQuestion": "Does the cost of delay exceed the value of waiting for more information — or is optionality more valuable than early commitment right now?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does the cost of delay exceed the value of waiting for more information — or is optionality more valuable than early commitment right now?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:75" ], "sourceComponents": "Act Triggers (cost of delay exceeds info value, time-sensitive opportunity, early-mover compounding advantage), Wait Triggers (high uncertainty with imminent resolution, downside of premature commitment, optionality value), Information Value Assessment (will waiting actually reduce uncertainty?), Opportunity Cost Calculation (what do you lose by waiting vs. what do you risk by acting?)", "sourceProcedure": "(1) For any commitment decision, assess: what is the cost of waiting one more cycle? → (2) Assess: will waiting actually produce meaningful new information? → (3) If waiting costs more than it teaches, act now → (4) If waiting teaches more than it costs, wait → (5) Check for compounding: does acting now create an advantage that grows over time? If yes, the cost of waiting is higher than it appears → (6) Check for optionality: does waiting preserve valuable options that acting would eliminate? If yes, the value of waiting is higher than it appears → (7) The default should be to act unless there is a specific, articulable reason to wait", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:75" ] }, { "@id": "urn:business-engineer:model:0076", "@type": "Model", "id": 76, "stableId": "BE-M0076", "name": "Bounded Rationality", "definition": "People make decisions under limits of information, time and computation; design processes that fit those limits.", "keyQuestion": "Am I designing for how people actually decide — or how I assume rational actors should decide?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I designing for how people actually decide — or how I assume rational actors should decide?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:76" ], "sourceComponents": "Satisficing (choosing \"good enough\" rather than optimal), Environmental Structure (the decision architecture shapes the decision), Cognitive Limits (attention, memory, processing constraints), Heuristic Reliance (mental shortcuts that usually work but systematically fail in specific conditions), Design Implication (design products, offers, and systems for bounded rationality, not perfect rationality)", "sourceProcedure": "(1) When modeling customer, competitor, or stakeholder behavior, do not assume perfect rationality → (2) Ask: what information do they actually have? What are their cognitive constraints? What heuristics are they using? → (3) Design your product/offer for how people actually decide, not how they theoretically should → (4) Simplify choices: reduce cognitive load, make the right option easiest → (5) Structure the environment: the architecture of the choice often matters more than the quality of the options → (6) Recognize your own bounded rationality: use frameworks and checklists to compensate for cognitive limits", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:76" ] }, { "@id": "urn:business-engineer:model:0077", "@type": "Model", "id": 77, "stableId": "BE-M0077", "name": "Less-is-More Heuristic", "definition": "A simpler rule can outperform a complex one when noise, data scarcity or decision cost outweigh added detail.", "keyQuestion": "Am I gathering more information because it will improve the decision — or because it feels safer than deciding?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I gathering more information because it will improve the decision — or because it feels safer than deciding?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:77" ], "sourceComponents": "Information Threshold (the point beyond which additional data degrades decision quality), Noise-to-Signal Ratio (more data often means more noise, not more signal), Analysis Paralysis (excessive information leads to decision avoidance), Overconfidence Trap (more data creates an illusion of precision without improving accuracy), Filtering as Strategy (the deliberate exclusion of information as a competitive advantage)", "sourceProcedure": "(1) Before gathering more data, ask: will this additional information change my decision? → (2) If the answer is no, stop gathering and decide → (3) Identify the 3-5 data points that actually drive the decision — ignore everything else → (4) Set a time limit: if you haven't decided in X hours with the data available, the constraint is not information — it's decision quality → (5) Practice deliberate information exclusion: for routine decisions, actively limit inputs → (6) Reserve deep analysis for Strategic Deliberation quadrant decisions (high impact, low reversibility) → (7) Treat filtering as a skill to develop, not a shortcut to justify", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:rent", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:77" ] }, { "@id": "urn:business-engineer:model:0078", "@type": "Model", "id": 78, "stableId": "BE-M0078", "name": "Ecological Rationality", "definition": "A decision rule's quality depends on how well it matches the structure and information of the environment in which it is used.", "keyQuestion": "Is this strategy suited to my specific environment — or am I importing something that worked elsewhere under different conditions?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this strategy suited to my specific environment — or am I importing something that worked elsewhere under different conditions?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:78" ], "sourceComponents": "Environment Assessment (what type of environment are you operating in — fast/slow, fragmented/consolidated, regulated/unregulated?), Strategy-Environment Fit (does the strategy match the environmental conditions?), Transplant Risk (strategies imported from different environments often fail), Adaptive Repertoire (maintaining multiple strategies for different conditions)", "sourceProcedure": "(1) Before adopting any strategy, characterize the environment: is it fast or slow? Fragmented or consolidated? Regulated or unregulated? → (2) Assess the strategy's original environment: where did it succeed, and why? → (3) Compare: do the conditions match? → (4) If conditions match, proceed with adaptation → (5) If conditions don't match, do not import — develop an environment-specific strategy → (6) Maintain a repertoire of strategies for different conditions — the ability to switch is itself an advantage → (7) When the environment changes, your strategy must change — loyalty to a strategy in a changed environment is a liability", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:78" ] }, { "@id": "urn:business-engineer:model:0079", "@type": "Model", "id": 79, "stableId": "BE-M0079", "name": "Contradiction Reading", "definition": "Treat contradictions between claims or observations as prompts to examine assumptions, units, incentives and regime differences.", "keyQuestion": "What structural driver is so powerful that it overrides this actor's stated principles — and what else does it predict?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What structural driver is so powerful that it overrides this actor's stated principles — and what else does it predict?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "A contradiction is a clue, not proof of a hidden structural imperative. Mistakes, hypocrisy, changed preferences and incomplete public information are competing explanations.", "calibration": "A contradiction is a clue, not proof of a hidden structural imperative. Mistakes, hypocrisy, changed preferences and incomplete public information are competing explanations.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:79" ], "sourceComponents": "Stated Principle (what the actor claims to value or prioritize), Observable Action (what the actor actually does), Contradiction Signal (the gap between principle and action), Structural Driver Hypothesis (the deeper force compelling the contradictory action), Validation (does the structural driver explain other contradictions by the same actor?)", "sourceProcedure": "(1) Observe any action that contradicts the actor's stated principles → (2) Do not dismiss it as hypocrisy — treat it as a signal → (3) Hypothesize: what structural force would make this contradictory action rational or inevitable? → (4) Test the hypothesis: does this structural driver explain other contradictions by the same actor? → (5) If it explains a pattern of contradictions, you've found the real driver → (6) This structural driver is usually more predictive of future actions than any stated principle", "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:79" ] }, { "@id": "urn:business-engineer:model:0080", "@type": "Model", "id": 80, "stableId": "BE-M0080", "name": "Existential Imperative Test", "definition": "Determine which strategic requirement is necessary for continued viability and distinguish it from attractive but optional improvements.", "keyQuestion": "What catastrophe are they trying to prevent — and does that existential threat explain everything else they're doing?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What catastrophe are they trying to prevent — and does that existential threat explain everything else they're doing?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "An existential threat is one hypothesis. Compare ordinary uncertainty, poor execution, incentives and strategic error; do not turn every surprising choice into a rational survival response.", "calibration": "An existential threat is one hypothesis. Compare ordinary uncertainty, poor execution, incentives and strategic error; do not turn every surprising choice into a rational survival response.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:80" ], "sourceComponents": "Surface Action (the seemingly irrational or surprising decision), Existential Question (\"What catastrophe happens if they don't do this?\"), Threat Mapping (what survival-level threat does this action address?), Validation (does this existential threat also explain other puzzling actions?), Predictive Power (what future actions does this existential threat predict?)", "sourceProcedure": "(1) Observe a decision that seems irrational, surprising, or excessive → (2) Ask: \"What catastrophe happens if they don't do this?\" → (3) Generate hypotheses: what existential threat could make this action rational? → (4) Test: does this threat also explain other seemingly puzzling actions by the same actor? → (5) If yes, you've identified the existential imperative → (6) Use it predictively: what other actions will this existential imperative force? → (7) The existential imperative is the most reliable predictor of organizational behavior — more reliable than strategy documents, earnings calls, or press releases", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:80" ] }, { "@id": "urn:business-engineer:model:0081", "@type": "Model", "id": 81, "stableId": "BE-M0081", "name": "AI-Native Organizational Archetypes", "definition": "Compare organizational forms for AI work by where expertise, authority, execution and learning reside; no single archetype fits every firm.", "keyQuestion": "Which organizational archetype best fits my strategy, culture, and competitive environment — and is my current structure enabling or constraining me?", "form": "archetype", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which organizational archetype best fits my strategy, culture, and competitive environment — and is my current structure enabling or constraining me?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:81" ], "sourceComponents": "Two-Layer Revolution (thin human strategy layer + AI execution layer — fast, scalable, but requires excellent strategic thinking at the top), Trust Network (autonomous teams + shared protocols + AI coordination — resilient, innovative, but requires deep trust and clear protocols), Slime Mold Organization (fluid self-organization + AI connective tissue — adaptive, responsive, but hard to manage and measure), Micro-Empire (individual/tiny team + AI augmentation achieving enterprise-level output — agile, low-cost, but limited by key-person risk)", "sourceProcedure": "(1) Assess your current organizational structure: which archetype are you closest to? → (2) Assess the environment: which archetype best fits your competitive landscape? → (3) If building new: choose the archetype that matches your strategy and culture → (4) If transforming: identify the target archetype and design the transition → (5) Each archetype has strengths and vulnerabilities — no archetype is universally best → (6) The key question is fit: does the structure enable the strategy, or does the structure constrain it?", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:81" ] }, { "@id": "urn:business-engineer:model:0082", "@type": "Model", "id": 82, "stableId": "BE-M0082", "name": "Super Individual Contributor", "definition": "AI can expand an individual's effective scope when task verification, context and coordination remain manageable.", "keyQuestion": "Am I creating conditions for Super ICs to emerge — or is my organizational structure forcing everyone into traditional roles?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I creating conditions for Super ICs to emerge — or is my organizational structure forcing everyone into traditional roles?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The role describes possible scope expansion. Team-equivalent output is task-dependent and must include quality, review and coordination costs.", "calibration": "The role describes possible scope expansion. Team-equivalent output is task-dependent and must include quality, review and coordination costs.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:82" ], "sourceComponents": "Deep Expertise (domain or technical mastery that provides judgment AI cannot replace), Strategic Thinking (ability to connect expertise to business outcomes), AI Augmentation (systematic use of AI to multiply output capacity), Cross-Functional Output (ability to produce across creation, analysis, strategy, and execution), Disproportionate Value (output significantly exceeding what the role traditionally produced)", "sourceProcedure": "(1) Identify individuals in your organization who combine deep expertise with strategic thinking → (2) Equip them with AI tools that amplify their specific strengths → (3) Remove organizational barriers that force them to specialize or manage → (4) Measure by output and value, not by activity or team size → (5) Restructure compensation to reflect disproportionate value creation → (6) Recognize: Super ICs may outperform entire teams — design the organization to accommodate this → (7) The Super IC is not a replacement for teams — it is a new organizational primitive that changes how teams are constructed", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:82" ] }, { "@id": "urn:business-engineer:model:0083", "@type": "Model", "id": 83, "stableId": "BE-M0083", "name": "Permanent Beta Organization", "definition": "Maintain a capacity for controlled experimentation and revision while preserving stable commitments, accountability and reliable operations.", "keyQuestion": "Is my organization built for continuous adaptation — or does it alternate between rigid stability and painful, disruptive reorganization?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my organization built for continuous adaptation — or does it alternate between rigid stability and painful, disruptive reorganization?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:83" ], "sourceComponents": "Provisional Everything (all processes, structures, and strategies are treated as hypotheses to be tested), Continuous Adaptation (change is constant and incremental, not periodic and disruptive), Minimum Viable Structure (just enough organization to execute, not so much that it resists change), Adaptation Rituals (regular reviews of what's working and what needs to evolve), Psychological Safety (people must feel safe challenging and changing established practices)", "sourceProcedure": "(1) Audit your organization: which structures are treated as permanent and which as provisional? → (2) For each \"permanent\" structure, ask: is this still serving us, or is it just familiar? → (3) Institute adaptation rituals: monthly reviews of processes, quarterly reviews of structures, annual reviews of strategy → (4) Reward adaptation: celebrate people who identify and improve outdated processes → (5) Maintain minimum viable structure: enough to execute, not so much that it resists necessary change → (6) Accept discomfort: permanent beta means never fully \"done\" — that's the feature, not the bug", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:83" ] }, { "@id": "urn:business-engineer:model:0084", "@type": "Model", "id": 84, "stableId": "BE-M0084", "name": "FRED Readiness Test", "aliases": [ "FRED Test" ], "definition": "Assess Foundational Readiness, Resource Allocation, Executive Alignment and Deployment Capability using observable evidence; ratings and gating thresholds require local calibration.", "keyQuestion": "Is my organization genuinely ready for AI transformation — or are we investing in AI theater?", "form": "framework", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my organization genuinely ready for AI transformation — or are we investing in AI theater?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "FRED means Foundational Readiness, Resource Allocation, Executive Alignment and Deployment Capability in this supplied formulation. Scores below 4 on a 1–10 scale are not a validated threshold; use observed evidence and explicit gates.", "calibration": "FRED means Foundational Readiness, Resource Allocation, Executive Alignment and Deployment Capability in this supplied formulation. Scores below 4 on a 1–10 scale are not a validated threshold; use observed evidence and explicit gates.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:84" ], "sourceComponents": "Foundational Readiness (data infrastructure, technical capabilities, integration readiness), Resource Allocation (budget, talent, time committed to AI transformation), Executive Alignment (leadership commitment beyond lip service — are they willing to restructure?), Deployment Capability (ability to move from proof-of-concept to production at scale)", "sourceProcedure": "(1) Rate the organization on each FRED dimension (1-10) → (2) Foundational: is the data infrastructure actually capable of supporting AI? (Most fail here) → (3) Resources: are real resources allocated, or is AI getting scraps from the innovation budget? → (4) Executive: are leaders willing to make structural changes, or do they want AI results without organizational change? → (5) Deployment: can the organization move from POC to production, or do proofs-of-concept die in the lab? → (6) If any dimension scores below 4, address that dimension before investing further in AI initiatives → (7) Be honest: AI theater is expensive and demoralizing", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:84" ] }, { "@id": "urn:business-engineer:model:0085", "@type": "Model", "id": 85, "stableId": "BE-M0085", "name": "AI Discernment Framework", "definition": "Judge when an AI output is useful, sufficiently reliable and appropriate to act on, including when expertise or verification is missing.", "keyQuestion": "Where does AI genuinely excel in my context, where does it fail, and what is the cost of getting it wrong?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where does AI genuinely excel in my context, where does it fail, and what is the cost of getting it wrong?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:85" ], "sourceComponents": "Capability Assessment (what can AI reliably do in this specific context?), Limitation Mapping (where does AI fail, hallucinate, or produce unreliable results?), Context Specificity (capabilities vary by domain, data quality, and task type), Boundary Monitoring (the capability-limitation boundary shifts rapidly — track it), Risk Calibration (what is the cost of AI failure in this application?)", "sourceProcedure": "(1) For any proposed AI application, assess: what can AI reliably do here today? → (2) Map limitations: where will it fail, and what are the consequences of failure? → (3) Evaluate context: do we have the right data, domain knowledge, and infrastructure for reliable AI performance? → (4) Calibrate risk: if AI fails in this application, what is the cost? → (5) Deploy AI where capabilities are strong and failure costs are manageable → (6) Maintain human oversight where limitations are known and failure costs are high → (7) Reassess regularly — the boundary moves fast", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:85" ] }, { "@id": "urn:business-engineer:model:0086", "@type": "Model", "id": 86, "stableId": "BE-M0086", "name": "Dual-Engine Framework", "definition": "Operate existing revenue and emerging capabilities with explicit resource allocation and interfaces so one does not silently starve the other.", "keyQuestion": "Am I running core optimization and AI transformation as parallel engines with separate resources — or am I expecting the core business to transform itself?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I running core optimization and AI transformation as parallel engines with separate resources — or am I expecting the core business to transform itself?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Separate engines can protect transformation work, but separation is not universally superior. Test the cost of duplicated systems, handoffs, incentives and isolation from real operations.", "calibration": "Separate engines can protect transformation work, but separation is not universally superior. Test the cost of duplicated systems, handoffs, incentives and isolation from real operations.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:86" ], "sourceComponents": "Engine 1 — Core Business (current operations optimization, revenue growth, efficiency improvement — measured by traditional business metrics), Engine 2 — AI Transformation (new capability building, model development, competitive positioning — measured by learning speed, capability milestones, strategic positioning), Resource Separation (each engine gets dedicated resources, not shared scraps), Interface Design (clear protocols for how the two engines communicate and transfer value)", "sourceProcedure": "(1) Separate the two engines organizationally — AI transformation cannot be a \"side project\" within the core business → (2) Allocate dedicated resources to each engine — not leftovers from the other → (3) Define separate metrics: Core Business = revenue, margin, efficiency; AI Transformation = learning speed, capability milestones, strategic positioning → (4) Design the interface: how do insights and capabilities transfer between engines? → (5) Protect Engine 2 from Engine 1's short-term pressures — this is the CEO's primary responsibility → (6) Plan the convergence: eventually the engines merge, but premature convergence kills transformation", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:86" ] }, { "@id": "urn:business-engineer:model:0087", "@type": "Model", "id": 87, "stableId": "BE-M0087", "name": "Productivity Spectrum", "definition": "Evaluate productivity at task, workflow and organizational levels, including quality, rework and displaced bottlenecks.", "keyQuestion": "Am I measuring AI productivity only as speed improvement — or am I capturing the full capability expansion it enables?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D08" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I measuring AI productivity only as speed improvement — or am I capturing the full capability expansion it enables?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:87" ], "sourceComponents": "Traditional Productivity (output per unit of time — the old metric), Capability Expansion (range of competencies an individual can now perform), Team-Level Competency (individual performing tasks that previously required multiple specialists), Output Quality vs. Quantity (AI doesn't just increase volume — it can improve quality across a wider range), New Value Creation (capability combinations that were impossible before AI augmentation)", "sourceProcedure": "(1) Audit current workflows: where are individuals limited by specialization, not capability? → (2) Identify AI tools that expand individual capability range → (3) Measure by capability expansion, not just speed improvement → (4) Redesign roles around expanded capability: can one person + AI do what a team of three did? → (5) Restructure teams: fewer, more capable individuals rather than many narrow specialists → (6) Invest in generalist-specialist hybrids: people who combine deep expertise in one area with AI-augmented competency across many → (7) Rethink compensation: value should reflect capability range, not just specialization depth", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:87" ] }, { "@id": "urn:business-engineer:model:0088", "@type": "Model", "id": 88, "stableId": "BE-M0088", "name": "Capability and Adaptability Matrix", "aliases": [ "Stupid-Out Matrix" ], "definition": "Compare capability with willingness and ability to adapt; use a neutral diagnostic rather than treating people as fixed derogatory categories.", "keyQuestion": "Am I building my team for the work that exists today — or the work that will exist tomorrow?", "form": "framework", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I building my team for the work that exists today — or the work that will exist tomorrow?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Use Capability and Adaptability Matrix as the neutral working label; retain Stupid-Out Matrix as a legacy search alias. Assess role-relevant evidence and development needs. A quadrant is not sufficient evidence for an employment decision.", "calibration": "Use Capability and Adaptability Matrix as the neutral working label; retain Stupid-Out Matrix as a legacy search alias. Assess role-relevant evidence and development needs. A quadrant is not sufficient evidence for an employment decision.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:88" ], "sourceComponents": "Stars (high capability + high adaptability — the core of AI-age teams), Specialists (high capability + low adaptability — valuable but vulnerable to change), Potential (low current capability + high adaptability — fast learners who will become stars with investment), Exit Zone (low capability + low adaptability — honest reassignment is kinder than pretending)", "sourceProcedure": "(1) Map your current team across both dimensions → (2) Stars: invest heavily, give maximum autonomy and AI tools → (3) Specialists: leverage their current value but invest in developing adaptability → (4) Potential: pair with mentors and AI tools, accelerate development → (5) Exit Zone: have honest conversations about fit and transition → (6) In hiring, weight adaptability more heavily than current capability — in a rapidly changing environment, the ability to learn matters more than what you already know → (7) Reassess regularly — people move between quadrants", "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:88" ] }, { "@id": "urn:business-engineer:model:0089", "@type": "Model", "id": 89, "stableId": "BE-M0089", "name": "Incumbent Vulnerability Analysis", "definition": "Assess incumbent vulnerability through incentives, architecture, distribution, resources and adaptation paths rather than size or age alone.", "keyQuestion": "Where is this incumbent most structurally vulnerable — and is it in a dimension I can exploit?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where is this incumbent most structurally vulnerable — and is it in a dimension I can exploit?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:89" ], "sourceComponents": "Market Position Complacency (has the incumbent stopped innovating because they feel safe?), Technology Debt (are legacy systems creating structural disadvantages?), Organizational Rigidity (can the incumbent adapt its structure, culture, and processes?), Margin Dependency (is the incumbent trapped by investor expectations for high margins?), Customer Dissatisfaction (are users genuinely loyal or simply lacking alternatives?)", "sourceProcedure": "(1) Select an incumbent to analyze → (2) Score each vulnerability dimension (1-10) based on observable evidence → (3) Market Position: look for signs of complacency — declining innovation, ignored complaints, internal focus → (4) Technology Debt: assess how much legacy infrastructure constrains their ability to adopt new approaches → (5) Organizational Rigidity: evaluate leadership's willingness and ability to change → (6) Margin Dependency: analyze how their margin structure constrains competitive response → (7) Customer Dissatisfaction: talk to customers — loyalty and lock-in look the same from outside but feel very different from inside → (8) The highest-scoring dimensions are the attack surfaces", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:89" ] }, { "@id": "urn:business-engineer:model:0090", "@type": "Model", "id": 90, "stableId": "BE-M0090", "name": "Market Structure Dynamics", "definition": "Explain market outcomes through entry barriers, differentiation, scale effects, bargaining positions and evolving concentration.", "keyQuestion": "What market structure state am I in, where is it heading, and is my strategy aligned with the transition dynamics?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What market structure state am I in, where is it heading, and is my strategy aligned with the transition dynamics?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:90" ], "sourceComponents": "Fragmented State (many small players, low barriers, high competition, innovation-driven), Consolidating State (winners emerging, M&A increasing, scale advantages appearing), Oligopoly State (few large players, high barriers, competition on efficiency and brand), Monopoly/Dominant State (one player controls, regulation becomes the primary competitive factor), Transition Drivers (technology shifts, regulation changes, network effects, capital concentration)", "sourceProcedure": "(1) Classify your market's current structural state → (2) Identify the transition drivers: what forces are pushing the market toward the next state? → (3) Fragmented → Consolidating: look for scale advantages and acquisition opportunities → (4) Consolidating → Oligopoly: invest in moats and differentiation before the market locks → (5) Oligopoly → Monopoly: either become the dominant player or find the niche the dominant player cannot serve → (6) At any state: look for disruption forces that could reset the market back to fragmented → (7) Strategy must match not just the current state but the direction of transition", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:90" ] }, { "@id": "urn:business-engineer:model:0091", "@type": "Model", "id": 91, "stableId": "BE-M0091", "name": "Capital Asymmetry of AI", "definition": "AI participants face different funding needs and access to capital; trace how those differences affect timing, resilience and strategic choices.", "keyQuestion": "How can I compete in AI despite not having hyperscaler-level capital — and what strategy fits my actual resource position?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How can I compete in AI despite not having hyperscaler-level capital — and what strategy fits my actual resource position?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:91" ], "sourceComponents": "Capital Concentration (where is AI investment concentrating — which companies, which layers?), Structural Divide (the widening gap between hyperscalers and everyone else), Competition Despite Asymmetry (strategies for competing without matching capital: specialization, efficiency, niche focus), Dependency Analysis (how dependent is your strategy on hyperscaler infrastructure?), Asymmetry Trajectory (is the gap widening or narrowing — and what would change the trajectory?)", "sourceProcedure": "(1) Map the capital landscape: who is spending how much on AI, and where? → (2) Assess your position: are you a hyperscaler, a mid-tier player, or a small player? → (3) If small/mid-tier: do not try to compete head-on with hyperscalers on compute or general models → (4) Instead, compete on specialization (deep domain expertise), efficiency (better results with less compute), niche focus (serving segments hyperscalers ignore), or leverage (building on hyperscaler infrastructure) → (5) Monitor dependency: if your strategy depends on a hyperscaler, understand the implications → (6) Watch for asymmetry shifts: technology breakthroughs (efficient models, edge AI) can reduce capital requirements", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:91" ] }, { "@id": "urn:business-engineer:model:0092", "@type": "Model", "id": 92, "stableId": "BE-M0092", "name": "AI Bubble vs Supercycle", "definition": "Separate inflated asset prices or financing expectations from durable technology adoption; speculative losses and useful infrastructure can coexist.", "keyQuestion": "Is this specific AI investment a bubble play or a supercycle play — and am I positioned to survive the correction while capturing the transformation?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this specific AI investment a bubble play or a supercycle play — and am I positioned to survive the correction while capturing the transformation?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Assess technology adoption, asset valuation and financing resilience separately. Transformation can coexist with poor investor returns, and strong adoption alone does not establish an attractive price.", "calibration": "Assess technology adoption, asset valuation and financing resilience separately. Transformation can coexist with poor investor returns, and strong adoption alone does not establish an attractive price.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:92" ], "sourceComponents": "Bubble Indicators (speculative capital, unrealistic valuations, limited adoption, hype-driven narratives), Supercycle Indicators (infrastructure investment, industry adoption, productivity gains, foundational technology change), Timing vs. Thesis Separation (the thesis can be right while the timing is wrong), Phase Assessment (where are we in the cycle — early hype, bubble peak, correction, real adoption?), Strategic Implication (how to position for both the short-term correction and the long-term transformation)", "sourceProcedure": "(1) Assess current AI investment: is it driven by speculation (bubble) or fundamental infrastructure (supercycle)? → (2) Look for bubble indicators: are valuations based on revenue or hope? Is adoption real or theoretical? → (3) Look for supercycle indicators: are large companies restructuring around AI? Are productivity gains measurable? → (4) The most likely answer: both — AI is simultaneously a bubble (some segments are overpriced) and a supercycle (the fundamental transformation is real) → (5) Position for both: don't dismiss AI as a bubble, but don't overpay for hype → (6) Focus on the supercycle fundamentals: infrastructure, adoption, productivity", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:institution" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:92" ] }, { "@id": "urn:business-engineer:model:0093", "@type": "Model", "id": 93, "stableId": "BE-M0093", "name": "Technology Supercycle", "aliases": [ "The Railroad Rhyme (Capital Ahead of Demand)" ], "definition": "A technology buildout can involve investment ahead of demand, local failures and later reuse; historical analogies require matched mechanisms and dates.", "keyQuestion": "Where is AI in the supercycle pattern — and what does history tell us about what happens next?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where is AI in the supercycle pattern — and what does history tell us about what happens next?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Historical waves differ in duration and sequence. A crash is not required before useful deployment, and 30–50 years is not a forecasting law. Verify the historical mechanism before transferring it.", "calibration": "Historical waves differ in duration and sequence. A crash is not required before useful deployment, and 30–50 years is not a forecasting law. Verify the historical mechanism before transferring it.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:257", "name": "Capital Ahead of Demand", "definition": "Historical buildouts can produce useful infrastructure while some investors lose money because funding, construction and demand develop at different speeds.", "evidence": "Verify each historical chronology, asset reuse, investment loss and demand path before borrowing the analogy.", "falsifier": "A case with different financing or asset economics weakens a direct historical comparison.", "limits": "Railways and fiber are examples, not exclusive correct analogies; exact panic and mileage claims need independent verification.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:93", "pack:257" ], "sourceComponents": "Invention Phase (the core technology breakthrough), Speculative Phase (excessive investment driven by potential, not reality), Correction Phase (bubble bursts, weak players eliminated, capital redirects), Infrastructure Phase (real buildout of the enabling infrastructure), Mass Adoption Phase (the technology becomes ubiquitous), Industry Restructuring Phase (existing industries fundamentally transformed), New Economic Paradigm (entirely new economic models emerge)", "sourceProcedure": "(1) Study previous supercycles: electricity (1880s-1930s), automobile (1900s-1950s), internet (1990s-2020s), mobile (2007-2030s) → (2) Map the AI supercycle against the pattern: where are we? (likely late speculative / early correction / early infrastructure) → (3) What happened at this stage in previous supercycles? Who won and who lost? → (4) Position for the infrastructure phase: that's where lasting competitive positions are built → (5) Do not confuse the correction (bubble bursting) with the end of the supercycle — the transformation is just beginning → (6) Plan on a 30-50 year horizon: what will the AI-transformed economy look like?", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:institution" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:93", "urn:business-engineer:source-entry:pack:257" ] }, { "@id": "urn:business-engineer:model:0094", "@type": "Model", "id": 94, "stableId": "BE-M0094", "name": "Negotiation Leverage Matrix", "definition": "Negotiating power depends on credible alternatives, dependency, information, timing and the ability to commit or walk away.", "keyQuestion": "Where does the real leverage sit in this negotiation — and have I strengthened my position across all five sources before entering?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where does the real leverage sit in this negotiation — and have I strengthened my position across all five sources before entering?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:94" ], "sourceComponents": "BATNA Strength (how good is your alternative if this deal fails?), Information Asymmetry (what do you know that the other side doesn't — and vice versa?), Time Pressure (who is under more urgency to close?), Relationship Capital (accumulated trust, goodwill, and reputation), Structural Position (market dynamics, supply/demand balance, competitive alternatives)", "sourceProcedure": "(1) Before any negotiation, map all five leverage sources for both sides → (2) BATNA: strengthen yours before entering — the ability to walk away is the most powerful lever → (3) Information: identify what you know that they don't and what they likely know that you don't → (4) Time: assess who is under more pressure — and never reveal your own time pressure → (5) Relationship: leverage accumulated trust, but never spend it recklessly → (6) Structural: understand market dynamics that favor or disadvantage your position → (7) The side with more leverage sources wins — but only if they deploy them deliberately", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:94" ] }, { "@id": "urn:business-engineer:model:0095", "@type": "Model", "id": 95, "stableId": "BE-M0095", "name": "Comparable Company Analysis", "aliases": [ "The Layer Multiple and the Reconciliation" ], "definition": "Use comparable companies only after aligning business exposure, accounting, growth, risk and capital needs; a multiple is a comparison, not an explanation.", "keyQuestion": "Is this company truly comparable to its supposed peers — or do structural and strategic differences make the financial comparison misleading?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this company truly comparable to its supposed peers — or do structural and strategic differences make the financial comparison misleading?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:225", "name": "Layer-Consistent Comparables", "definition": "Choose valuation comparables according to economic function, cash-flow quality, growth, risk and capital requirements.", "evidence": "Reconcile numerator, denominator, business mix and reinvestment across the comparable set.", "falsifier": "A different layer with demonstrably similar economics can outperform a superficially similar peer.", "limits": "Layer labels do not establish comparability on their own.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:95", "pack:225" ], "sourceComponents": "Financial Comparison (revenue, margins, growth rates, valuation multiples), Structural Comparison (moat type and strength, flywheel maturity, constraint profile), Strategic Comparison (archetype alignment, competitive positioning, market layer), Positional Comparison (market share trajectory, customer loyalty indicators, brand strength), Divergence Detection (where does this company look comparable on financials but diverge structurally?)", "sourceProcedure": "(1) Define the peer set: which companies are genuinely comparable in market, strategy, and structure? → (2) Compare financials: revenue, margins, growth, valuation — the baseline → (3) Compare structurally: moat quality, flywheel maturity, binding constraints → (4) Compare strategically: are they the same archetype, targeting the same layer, with the same competitive logic? → (5) Compare positionally: is their market position strengthening or weakening relative to peers? → (6) Identify divergences: where do financials look similar but structural or strategic positions diverge? → (7) The divergences are the insight — they reveal mispricing, hidden risk, or hidden opportunity", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:95", "urn:business-engineer:source-entry:pack:225" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0096", "@type": "Model", "id": 96, "stableId": "BE-M0096", "name": "Agentic Web Visibility Playbook", "definition": "Assess whether agents can discover, interpret and cite an entity in relevant tasks; visibility is distinct from transaction authority or conversion.", "keyQuestion": "Is my visibility strategy designed for AI agents as well as human users — or am I invisible to the emerging agentic discovery layer?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my visibility strategy designed for AI agents as well as human users — or am I invisible to the emerging agentic discovery layer?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Treat machine-readable content as one possible contributor to discoverability. Current platform behavior, coverage and commercial impact require measurement.", "calibration": "Treat machine-readable content as one possible contributor to discoverability. Current platform behavior, coverage and commercial impact require measurement.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:96" ], "sourceComponents": "Agent Discovery Optimization (how AI agents find and evaluate your offering), Structured Data Architecture (machine-readable information that agents can process), Protocol Compliance (adherence to emerging agent communication standards), Authority Signals (indicators that agents use to assess trustworthiness and quality), Machine-Readable Value Proposition (your offering expressed in formats agents can parse and compare)", "sourceProcedure": "(1) Audit your current visibility strategy: is it designed for human browsers or AI agents? → (2) Implement structured data that agents can parse: schema markup, APIs, standardized formats → (3) Ensure protocol compliance: adopt emerging agent communication standards early → (4) Build authority signals: consistent quality, verified credentials, institutional endorsements → (5) Express your value proposition in machine-readable formats, not just human-readable copy → (6) Monitor agent-mediated traffic: how are AI agents finding and presenting your offering? → (7) This is not replacing human-focused visibility — it is adding an agent-focused layer", "usesConcept": [ "urn:business-engineer:concept:authority" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:96" ] }, { "@id": "urn:business-engineer:model:0097", "@type": "Model", "id": 97, "stableId": "BE-M0097", "name": "Digital Distribution Layers", "definition": "Separate distribution layers and their interfaces to identify who controls access, demand, discovery and monetization.", "keyQuestion": "How much of my distribution do I actually control — and what happens if the platforms or algorithms change their rules?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of my distribution do I actually control — and what happens if the platforms or algorithms change their rules?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:97" ], "sourceComponents": "Platform Layer (distribution controlled by platform gatekeepers — rules, fees, visibility), Algorithmic Layer (distribution shaped by recommendation engines — amplification, suppression, ranking), Direct Layer (distribution controlled by the creator/company — email lists, communities, direct relationships), Layer Diversification (spreading distribution across all three to reduce dependency), Control Assessment (how much control do you have at each layer?)", "sourceProcedure": "(1) Map your current distribution: what percentage flows through platform, algorithmic, and direct channels? → (2) Assess vulnerability: if one layer changes its rules, how much traffic do you lose? → (3) Platform layer: maintain presence but do not depend — platform rules change without notice → (4) Algorithmic layer: understand the algorithm's incentives and optimize accordingly, but do not build your entire strategy on it → (5) Direct layer: invest heavily — this is the only layer you truly control → (6) Target: at least 30% of distribution through direct channels → (7) Diversify across all three, with increasing investment in direct over time", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:97" ] }, { "@id": "urn:business-engineer:model:0098", "@type": "Model", "id": 98, "stableId": "BE-M0098", "name": "Brand Authority in AI Agent Age", "definition": "Authority may help an entity be selected by humans and agents, but its effect depends on retrieval, evidence, task and platform behavior.", "keyQuestion": "Is my brand strong enough to serve as a trust signal for AI agents — or will agent-mediated discovery render me invisible?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my brand strong enough to serve as a trust signal for AI agents — or will agent-mediated discovery render me invisible?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Brand effects on agent recommendations are empirical and platform-dependent. More important is a hypothesis, not an automatic consequence of AI mediation.", "calibration": "Brand effects on agent recommendations are empirical and platform-dependent. More important is a hypothesis, not an automatic consequence of AI mediation.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:98" ], "sourceComponents": "Agent Trust Signals (how does brand authority translate into signals that AI agents use to rank and recommend?), Human Validation Layer (how does brand familiarity help humans trust agent recommendations?), Brand-Agent Feedback Loop (strong brand → agent recommendation → user trust → purchase → stronger brand), Authority Accumulation (how is brand authority built in an agent-mediated world?), Vulnerability Assessment (what happens to weak brands when agents mediate discovery?)", "sourceProcedure": "(1) Assess your current brand authority: is it strong enough to serve as an agent trust signal? → (2) Map how AI agents currently perceive and rank your brand (reviews, structured data, institutional signals) → (3) Invest in the brand-agent feedback loop: strong brand → agent recommendations → user trust → purchase → stronger brand → (4) Build authority signals that agents recognize: consistent quality, verified credentials, positive user data → (5) For weak brands: the agent-mediated world is more dangerous — invest in brand building before agents fully mediate your market → (6) Brand is not just for humans anymore — it is infrastructure for the agentic web", "usesConcept": [ "urn:business-engineer:concept:authority" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:98" ] }, { "@id": "urn:business-engineer:model:0099", "@type": "Model", "id": 99, "stableId": "BE-M0099", "name": "AI Search Paradigm Shift", "definition": "Evaluate how AI-mediated search changes discovery, referral and conversion using task-specific observations rather than a universal displacement claim.", "keyQuestion": "Is my content and digital presence designed for the Crawl-Index-Rank world or the Retrieve-Memory-Reason world — and am I adapting fast enough?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is my content and digital presence designed for the Crawl-Index-Rank world or the Retrieve-Memory-Reason world — and am I adapting fast enough?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "AI retrieval can still depend on crawling, indexing and ranking. Retrieve-Memory-Reason is a conceptual lens, not a universal replacement architecture or evidence that every system has persistent memory.", "calibration": "AI retrieval can still depend on crawling, indexing and ranking. Retrieve-Memory-Reason is a conceptual lens, not a universal replacement architecture or evidence that every system has persistent memory.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:99" ], "sourceComponents": "Old Model — Crawl-Index-Rank (search engines crawl content, build indexes, rank by keyword relevance and authority signals), New Model — Retrieve-Memory-Reason (AI retrieves information, remembers context, reasons about answers), Visibility Implications (being cited by AI requires different signals than ranking in search results), Content Strategy Implications (content must be authoritative and comprehensive, not keyword-optimized), Distribution Implications (direct answers replace link lists — the click may never happen)", "sourceProcedure": "(1) Understand the shift: AI search does not list links — it provides answers derived from multiple sources → (2) Audit your content: is it optimized for keyword ranking (old model) or for being cited as an authoritative source (new model)? → (3) Invest in comprehensive, authoritative content that AI systems will choose to cite → (4) Build structured data that AI can retrieve and process → (5) Accept: in the new model, the user may never click through — your content must deliver value even when consumed by an AI intermediary → (6) Monitor AI citations: how often are AI systems referencing your content? → (7) This shift is not coming — it is here. Adapt now or lose discoverability", "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:99" ] }, { "@id": "urn:business-engineer:model:0100", "@type": "Model", "id": 100, "stableId": "BE-M0100", "name": "Bullseye Framework", "definition": "Test multiple acquisition channels, concentrate on promising evidence and measure conversion economics before scaling a channel.", "keyQuestion": "Have I found my Bullseye distribution channel — or am I spreading resources across too many channels and dominating none?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Have I found my Bullseye distribution channel — or am I spreading resources across too many channels and dominating none?", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:100" ], "sourceComponents": "Channel Universe (all possible distribution channels — 19+ categories), Ranking Criteria (potential reach, cost, speed, fit with audience, competitive saturation), Top 3 Testing (cheap, fast experiments on the highest-potential channels), Bullseye Identification (the single channel that outperforms all others for your specific business), Concentration Discipline (doubling down on the Bullseye rather than spreading across many channels)", "sourceProcedure": "(1) List all possible distribution channels (content, SEO, paid ads, PR, partnerships, community, events, referrals, etc.) → (2) Rank by potential for your specific business and audience — not what works in general, but what works for you → (3) Select the top 3 and design cheap, fast tests for each → (4) Run the tests simultaneously with clear success metrics → (5) Identify the Bullseye: which channel delivered the best results relative to cost and effort? → (6) Concentrate resources on the Bullseye channel — dominate it before diversifying → (7) Revisit quarterly: the Bullseye can shift as the business grows and the market evolves", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:100" ] }, { "@id": "urn:business-engineer:model:0101", "@type": "Model", "id": 101, "stableId": "BE-M0101", "name": "Antifragility (Taleb)", "definition": "An antifragile system can benefit from some forms of variability or disorder within bounded exposure; this is distinct from merely surviving shocks.", "keyQuestion": "Does my system get stronger from stress — or am I one shock away from breaking?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does my system get stronger from stress — or am I one shock away from breaking?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Preserve Taleb’s attribution. Benefit from a bounded class of variability does not imply benefit from all shocks; specify exposure, survivability and the mechanism of improvement.", "calibration": "Preserve Taleb’s attribution. Benefit from a bounded class of variability does not imply benefit from all shocks; specify exposure, survivability and the mechanism of improvement.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:101" ], "sourceComponents": "Fragile Systems (break under stress — centralized, over-optimized, brittle), Robust Systems (survive stress without improving — stable but static), Antifragile Systems (strengthen from stress — decentralized, optionality-rich, exposure to small shocks), Optionality (maintaining many small options rather than one large bet), Barbell Strategy (combine extreme safety with extreme risk, avoiding the middle)", "sourceProcedure": "(1) Assess your organization/strategy: is it fragile, robust, or antifragile? → (2) Reduce fragility: eliminate single points of failure, reduce over-optimization, build redundancy → (3) Build antifragility: create optionality (many small bets), expose the system to small stresses deliberately, design feedback loops that convert stress into learning → (4) Apply the barbell: keep 80-90% extremely safe while exposing 10-20% to extreme upside potential → (5) Embrace volatility: in an antifragile system, each shock is a training event, not a crisis", "usesConcept": [ "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:101" ] }, { "@id": "urn:business-engineer:model:0102", "@type": "Model", "id": 102, "stableId": "BE-M0102", "name": "Day 1 Mentality (Bezos)", "definition": "Use a Day 1 orientation to sustain customer attention, experimentation and responsiveness while retaining operating discipline.", "keyQuestion": "Are we on Day 1 or Day 2 — and what specific symptoms indicate which?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Are we on Day 1 or Day 2 — and what specific symptoms indicate which?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:102" ], "sourceComponents": "Customer Obsession (decisions start and end with the customer, not the competitor or the process), High-Velocity Decision-Making (most decisions are reversible — make them quickly with 70% of the information you wish you had), Experimentation Bias (willingness to fail, willingness to be misunderstood for long periods), Process Skepticism (processes serve outcomes, not the reverse — when process becomes the proxy for outcome, you're on Day 2), External Focus (the outside world is always Day 1 — internal comfort is the enemy)", "sourceProcedure": "(1) Diagnose: is your organization on Day 1 or Day 2? → (2) Day 2 symptoms: slow decisions, process worship, customer as abstraction, internal focus, resistance to experimentation → (3) Restore Day 1 by re-centering on customer obsession: every meeting starts with \"what does the customer need?\" → (4) Accelerate decisions: adopt the 70% rule — decide with 70% of desired information, correct course later → (5) Reward experimentation and tolerate failure → (6) Attack process that has become proxy for outcomes → (7) Day 1 is not a state you reach — it is a discipline you maintain daily", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:102" ] }, { "@id": "urn:business-engineer:model:0103", "@type": "Model", "id": 103, "stableId": "BE-M0103", "name": "First Principles (Musk)", "definition": "Decompose a problem into defensible assumptions and constraints, then reconstruct alternatives rather than inheriting a conventional solution.", "keyQuestion": "Which assumptions am I treating as fixed that are actually just convention — and what happens when I reason from base truths instead?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which assumptions am I treating as fixed that are actually just convention — and what happens when I reason from base truths instead?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "First-principles reasoning predates Musk. The name in the source refers to a modern popularizer/application, not the originator of the method.", "calibration": "First-principles reasoning predates Musk. The name in the source refers to a modern popularizer/application, not the originator of the method.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:103" ], "sourceComponents": "Assumption Identification (what assumptions is everyone treating as fixed?), Decomposition (break the problem into its most fundamental components), Base Truth Validation (verify each component against physics, logic, or evidence — not convention), Reconstruction (rebuild the solution from validated base truths), Convention Challenge (the value is proportional to how many accepted assumptions you overturn)", "sourceProcedure": "(1) Select a strategic problem where conventional approaches have stalled → (2) List every assumption embedded in the conventional approach → (3) For each assumption, ask: is this physically/logically true, or is it just convention? → (4) Discard assumptions that are convention, keep those that are fundamental truths → (5) Rebuild the solution from the remaining base truths — this often produces radically different approaches → (6) Apply selectively: first principles thinking is expensive — reserve it for decisions where the payoff of challenging convention is highest → (7) The output should feel uncomfortable — if it feels familiar, you haven't gone deep enough", "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:103" ] }, { "@id": "urn:business-engineer:model:0104", "@type": "Model", "id": 104, "stableId": "BE-M0104", "name": "Value Investing (Buffett)", "definition": "Compare price with a conservatively estimated range of intrinsic value while considering uncertainty, downside and the reliability of the valuation inputs.", "keyQuestion": "Is this opportunity priced below its intrinsic value — and do I have the patience and conviction to wait for convergence?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this opportunity priced below its intrinsic value — and do I have the patience and conviction to wait for convergence?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Preserve Buffett’s association while recognizing the earlier value-investing tradition. Intrinsic value is uncertain and strategy should test assumptions rather than presume a true price.", "calibration": "Preserve Buffett’s association while recognizing the earlier value-investing tradition. Intrinsic value is uncertain and strategy should test assumptions rather than presume a true price.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:104" ], "sourceComponents": "Intrinsic Value Assessment (what is the true, structural value — independent of market sentiment?), Margin of Safety (buy only when the price is significantly below intrinsic value), Long-Term Orientation (hold through short-term volatility when the thesis remains intact), Circle of Competence (invest only in areas you deeply understand), Contrarian Patience (willingness to wait, to be wrong in the short term, to look foolish until the thesis plays out)", "sourceProcedure": "(1) Develop an independent assessment of intrinsic value for the asset, opportunity, or strategy → (2) Compare to the market price or consensus view: is there a gap? → (3) Demand a margin of safety: don't invest unless the gap is significant → (4) Stay within your circle of competence: the value assessment is only as good as your understanding → (5) Be patient: intrinsic value and market price converge eventually, but timing is unpredictable → (6) Apply to non-financial decisions: undervalued talent, undervalued niches, undervalued strategies → (7) The discipline: buy when others are fearful, hold when others are impatient", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:104" ] }, { "@id": "urn:business-engineer:model:0105", "@type": "Model", "id": 105, "stableId": "BE-M0105", "name": "Moonshot Thinking (Page)", "definition": "Pursue a large improvement by challenging limiting assumptions and testing feasibility; ambition alone does not justify the investment.", "keyQuestion": "If I needed 10x improvement instead of 10%, what approach would I take — and why am I not taking it?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "If I needed 10x improvement instead of 10%, what approach would I take — and why am I not taking it?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "A 10x target can expand the solution space, but is not generally easier than a 10% gain. Evaluate feasibility, resources and downside.", "calibration": "A 10x target can expand the solution space, but is not generally easier than a 10% gain. Evaluate feasibility, resources and downside.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:105" ], "sourceComponents": "10x Reframing (state the goal as 10x the current level — not incrementally better, but radically different), Solution Space Shift (10x goals make current approaches irrelevant, forcing new solution architectures), Constraint Breaking (10x goals reveal which constraints are real and which are assumed), Ambitious Talent Attraction (10x goals attract people who are bored by incremental work), Selective Application (not every problem deserves moonshot thinking — apply to the highest-leverage challenges)", "sourceProcedure": "(1) Identify a strategic challenge where incremental progress has stalled → (2) Restate the goal as 10x: if you needed to be 10x better, faster, or cheaper, what would change? → (3) Notice: the 10x framing immediately invalidates most current approaches → (4) Generate new approaches that could only work at 10x — these are usually more inventive and sometimes simpler → (5) Evaluate: which of these 10x approaches might actually work? → (6) Even if you achieve 5x instead of 10x, you've far exceeded what incremental optimization would have delivered → (7) Apply selectively: moonshot thinking is powerful but exhausting — reserve it for the highest-leverage problems", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:105" ] }, { "@id": "urn:business-engineer:model:0106", "@type": "Model", "id": 106, "stableId": "BE-M0106", "name": "Zero to One (Thiel)", "definition": "Seek a distinct valuable capability or market position rather than assuming incremental competition is the only path to growth.", "keyQuestion": "Am I creating genuinely new value (0 to 1) or competing for existing value (1 to n) — and what is my secret?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I creating genuinely new value (0 to 1) or competing for existing value (1 to n) — and what is my secret?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "New invention and adaptation can both create durable value; neither novelty nor a contrarian belief establishes a monopoly.", "calibration": "New invention and adaptation can both create durable value; neither novelty nor a contrarian belief establishes a monopoly.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:106" ], "sourceComponents": "Zero to One (vertical innovation — creating something the world has never seen), One to N (horizontal scaling — copying and distributing what already exists), The Secret (a truth you believe that most disagree with — the foundation of 0-to-1 companies), Monopoly Building (the goal is not competition but a category of one — where competition is irrelevant), Definite Optimism (the belief that the future is better AND that you can shape it through specific plans)", "sourceProcedure": "(1) Ask: is your business creating new value or redistributing existing value? → (2) If redistributing: you are in a 1-to-n business — expect competition and thin margins → (3) If creating: identify your secret — the insight that others believe is wrong → (4) Test the secret: if you tell smart people, do they disagree? If everyone agrees, it's not a secret → (5) Build a monopoly around the secret: dominate a small market completely before expanding → (6) Avoid competition: if you're competing, you're not doing 0-to-1 — find the space where competition is irrelevant → (7) The strategic test: are you building a company that the world doesn't yet know it needs?", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:residual-value", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:106" ] }, { "@id": "urn:business-engineer:model:0107", "@type": "Model", "id": 107, "stableId": "BE-M0107", "name": "Blitzscaling (Hoffman)", "definition": "Prioritize rapid scale under specific competitive conditions while explicitly accepting and monitoring the resulting inefficiency and risk.", "keyQuestion": "Does this market have winner-take-all dynamics that justify prioritizing speed over efficiency — or am I burning capital without building a defensible position?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this market have winner-take-all dynamics that justify prioritizing speed over efficiency — or am I burning capital without building a defensible position?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Blitzscaling depends on financing capacity, market structure and survivable execution risks. It is not automatically correct whenever network effects exist.", "calibration": "Blitzscaling depends on financing capacity, market structure and survivable execution risks. It is not automatically correct whenever network effects exist.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:107" ], "sourceComponents": "Speed Over Efficiency (deliberately accepting operational chaos to grow faster), Winner-Take-All Conditions (blitzscaling is only correct when network effects create WTA dynamics), Acceptable Inefficiency (waste is the price of speed — budget for it), Competitive Timing (the window during which speed creates an insurmountable advantage), Exit Conditions (when to stop blitzscaling and shift to optimization)", "sourceProcedure": "(1) First, verify WTA conditions: does this market have strong network effects, high switching costs, and data returns to scale? → (2) If no: do NOT blitzscale — you'll burn capital without building defensible position → (3) If yes: assess the competitive window — how long before the market tips to a winner? → (4) During the window: prioritize speed over efficiency — accept higher costs, organizational chaos, and imperfect execution → (5) Measure: are you gaining market share faster than competitors? → (6) Set exit conditions: when the market has tipped (to you or against you), shift immediately from speed to efficiency → (7) The most common error: blitzscaling in markets that don't have WTA dynamics", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:107" ] }, { "@id": "urn:business-engineer:model:0108", "@type": "Model", "id": 108, "stableId": "BE-M0108", "name": "Move Fast (Zuckerberg)", "definition": "Increase learning speed through rapid iteration within boundaries appropriate to reversibility, user impact and operational risk.", "keyQuestion": "How fast am I iterating — and what is the bottleneck preventing me from iterating faster?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How fast am I iterating — and what is the bottleneck preventing me from iterating faster?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:108" ], "sourceComponents": "Iteration Speed (how fast can you ship, measure, and learn?), Feedback Value (the insight gained from shipping exceeds the insight gained from planning), Stage Adaptation (early: speed > quality; growth: speed + quality; scale: speed + quality + stability), Speed Culture (organizational norms, tools, and incentives that preserve speed), Complexity Management (maintaining speed as organizational and product complexity grows)", "sourceProcedure": "(1) Measure your iteration speed: how long from idea to shipped product to measured outcome? → (2) If the cycle is weeks or months, it's too slow — find the bottleneck and eliminate it → (3) Early stage: prioritize speed ruthlessly — ship imperfect products, learn from real users → (4) Growth stage: add quality guardrails without sacrificing speed — automation, testing, CI/CD → (5) Scale stage: add stability infrastructure — but the moment speed drops, treat it as a crisis → (6) Build a speed culture: reward shipping, not planning; reward learning, not perfection → (7) The enemy is not failure — it is slowness", "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:reversibility" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:108" ] }, { "@id": "urn:business-engineer:model:0109", "@type": "Model", "id": 109, "stableId": "BE-M0109", "name": "Simplicity (Jobs)", "definition": "Reduce complexity in a product or decision while preserving the capabilities and distinctions its intended user needs.", "keyQuestion": "What can I remove without losing value — and have I understood this deeply enough to make it simple?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What can I remove without losing value — and have I understood this deeply enough to make it simple?", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Clarity is valuable, but some problems retain irreducible complexity. Compress language without deleting uncertainty or causal structure.", "calibration": "Clarity is valuable, but some problems retain irreducible complexity. Compress language without deleting uncertainty or causal structure.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:109" ], "sourceComponents": "Deep Understanding (simplicity requires deeper understanding than complexity — you must know what to cut), Ruthless Elimination (every element must justify its existence — if it doesn't add clear value, remove it), Focus as Strategy (saying no to a thousand things to say yes to one), User Experience Obsession (the user's experience is the final arbiter of simplicity), Iterative Refinement (simplicity is reached through many rounds of stripping away, not through initial design)", "sourceProcedure": "(1) Take any product, strategy, or analysis and ask: what can be removed without losing value? → (2) Remove it. Ask again. Repeat until removing anything would destroy value → (3) Test: can a new user/reader understand this without explanation? If not, simplify further → (4) Focus: what is the ONE thing this product/strategy/analysis must do brilliantly? Everything else is subordinate → (5) Resist the temptation to add: every new feature, element, or qualification is a cost to simplicity → (6) Simplicity is a competitive advantage: simpler products win because they're easier to use, explain, and spread → (7) If it's still complex, you don't understand it well enough yet", "usesConcept": [ "urn:business-engineer:concept:portability", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:109" ] }, { "@id": "urn:business-engineer:model:0110", "@type": "Model", "id": 110, "stableId": "BE-M0110", "name": "Customer Obsession (Bezos/Wilke)", "definition": "Use customer problems and observed behavior to guide priorities, while distinguishing expressed requests from underlying needs and viable economics.", "keyQuestion": "Am I starting with the customer's need and working backward — or starting with my capabilities and hoping they match?", "form": "heuristic", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I starting with the customer's need and working backward — or starting with my capabilities and hoping they match?", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Customer benefit is central but must coexist with economic sustainability and obligations to other stakeholders. It does not guarantee the winning strategy.", "calibration": "Customer benefit is central but must coexist with economic sustainability and obligations to other stakeholders. It does not guarantee the winning strategy.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:110" ], "sourceComponents": "Customer as Starting Point (every initiative begins with the customer's need, not the company's capability), Working Backwards (start with the desired customer experience and work backward to the technology, process, and organization required), Long-Term Customer Value (optimize for lifetime customer relationship, not short-term extraction), Customer Signal Primacy (customer feedback, behavior, and complaints are the highest-priority data), Competitor Blindness (do not copy competitors — obsess over what the customer needs that no one is providing)", "sourceProcedure": "(1) For every initiative, start with: what does the customer need? Not what can we build, not what are competitors doing → (2) Work backward from the ideal customer experience to the required technology, process, and organization → (3) Optimize for long-term customer value: sacrifice short-term revenue for lifetime relationship when necessary → (4) Elevate customer signals: make customer feedback, complaints, and behavior data the most visible metrics in the organization → (5) Ignore competitors as the primary reference point — obsess over unmet customer needs → (6) The tiebreaker: when torn between options, choose the one that is better for the customer → (7) Customer obsession is not being nice — it is a strategic doctrine that compounds over decades", "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:obligation" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:110" ] }, { "@id": "urn:business-engineer:model:0111", "@type": "Model", "id": 111, "stableId": "BE-M0111", "name": "Operating Absorption and Capital Intensity", "aliases": [ "Revenue vs Depreciation, Not Revenue vs Capex" ], "definition": "Compare revenue with operating costs and depreciation for operating absorption; separately compare cash flows with capex for funding and investment returns.", "keyQuestion": "Is revenue covering the depreciation of what's already built — and is it growing faster than the depreciation wave that's coming?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is revenue covering the depreciation of what's already built — and is it growing faster than the depreciation wave that's coming?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Revenue and capex are both period flows. Capex/revenue is a valid capital-intensity ratio; it is not an investment-return test. Analyze revenue, operating costs and depreciation for profitability, capex and working capital for cash flow, and discounted future cash flows for capital returns.", "calibration": "Revenue and capex are both period flows. Capex/revenue is a valid capital-intensity ratio; it is not an investment-return test. Analyze revenue, operating costs and depreciation for profitability, capex and working capital for cash flow, and discounted future cash flows for capital returns.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:111" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:operating-absorption", "urn:business-engineer:concept:counting-boundary" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:111" ], "instruments": [ "urn:business-engineer:instrument:capital-print", "urn:business-engineer:instrument:reconciliation" ], "modes": [ "urn:business-engineer:mode:print" ] }, { "@id": "urn:business-engineer:model:0112", "@type": "Model", "id": 112, "stableId": "BE-M0112", "name": "Capital Recovery Hurdle", "aliases": [ "The Beat Raises the Hurdle", "The Hurdle Is Arithmetic" ], "definition": "Calculate the cash contribution needed to support invested capital under explicit timing, life, margin, return and salvage assumptions.", "keyQuestion": "What revenue does the deployed capital arithmetically require — and what fraction of it exists today?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What revenue does the deployed capital arithmetically require — and what fraction of it exists today?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The supplied K × (1/n + r) ÷ margin is a rough capital-charge approximation, not an exact return hurdle. For a level end-of-year pre-tax cash-contribution stream and zero salvage, annual capital recovery is K × r/[1−(1+r)^(-n)], or K/n at r=0. Add relevant fixed cash costs and divide by a clearly defined cash-contribution margin; model taxes, ramp, working capital, replacements and residual value separately.", "calibration": "The supplied K × (1/n + r) ÷ margin is a rough capital-charge approximation, not an exact return hurdle. For a level end-of-year pre-tax cash-contribution stream and zero salvage, annual capital recovery is K × r/[1−(1+r)^(-n)], or K/n at r=0. Add relevant fixed cash costs and divide by a clearly defined cash-contribution margin; model taxes, ramp, working capital, replacements and residual value separately.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:158", "name": "Supplier Shipments and the Monetization Hurdle", "definition": "An increase in supplier shipments can increase the asset vintages and commitments that customers must monetize; update the return hurdle using actual capital exposure and the expected demand path.", "evidence": "Trace shipments into installed capacity, timing, customer obligations and incremental final-demand cash flows; distinguish replacements and inventory from additional productive capital.", "falsifier": "Replacement shipments, falling total capital cost or independently rising profitable utilization can overturn an inferred increase in the monetization gap.", "limits": "A supplier beat is not automatically evidence against monetization. Reconcile capital and revenue boundaries; capex at three times depreciation alone implies no fixed revenue growth rate.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:112", "pack:158" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counting-boundary", "urn:business-engineer:concept:residual-value" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:112", "urn:business-engineer:source-entry:pack:158" ], "instruments": [ "urn:business-engineer:instrument:reconciliation" ] }, { "@id": "urn:business-engineer:model:0113", "@type": "Model", "id": 113, "stableId": "BE-M0113", "name": "Allocation Becomes Obligation", "definition": "A planned capital allocation becomes an exposure as contractual commitments, construction and financing reduce the ability to cancel or redirect it.", "keyQuestion": "Has the funding character changed from discretionary allocation to third-party obligation — and did anyone re-rate the risk when it did?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Has the funding character changed from discretionary allocation to third-party obligation — and did anyone re-rate the risk when it did?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Self-funded programs can still have binding purchase, lease and labor commitments. Funding source and contractual obligation are separate dimensions; neither external funding nor operating-cash-flow funding alone determines flexibility.", "calibration": "Self-funded programs can still have binding purchase, lease and labor commitments. Funding source and contractual obligation are separate dimensions; neither external funding nor operating-cash-flow funding alone determines flexibility.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:113" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:113" ] }, { "@id": "urn:business-engineer:model:0114", "@type": "Model", "id": 114, "stableId": "BE-M0114", "name": "Absorption Capacity", "definition": "Measure whether an actor can carry a new obligation through operating earnings, cash generation, liquidity and funding access without conflating the tests.", "keyQuestion": "What is this company's capital intensity — and where does that place it on the clock relative to peers running the same build?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is this company's capital intensity — and where does that place it on the clock relative to peers running the same build?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:114" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:counting-boundary" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:114" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0115", "@type": "Model", "id": 115, "stableId": "BE-M0115", "name": "Operating Absorption ≠ Cash Absorption", "aliases": [ "Stretch From Strength" ], "definition": "Separate the operating capacity to bear depreciation and expenses from the cash capacity to fund investment, working capital and maturities.", "keyQuestion": "Does the operating answer match the cash answer — and if not, which one is the market pricing?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does the operating answer match the cash answer — and if not, which one is the market pricing?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "An operating/cash divergence is a diagnostic, not a verdict of strength or distress. Explain its sources, duration, commitments and available liquidity.", "calibration": "An operating/cash divergence is a diagnostic, not a verdict of strength or distress. Explain its sources, duration, commitments and available liquidity.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:159", "name": "Operating and Cash Absorption", "definition": "A company can cover operating charges while stretching its ability to fund investment, maturities and working capital.", "evidence": "Reconcile operating earnings, cash generation, capex, commitments and liquidity over matching periods.", "falsifier": "Adequate stressed funding coverage weakens a claim of cash strain despite heavy investment.", "limits": "Operating strength and funding resilience are separate tests.", "mappingKind": "equivalentMechanism" } ], "sourceIds": [ "base:115", "pack:159" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:operating-absorption", "urn:business-engineer:concept:cash-absorption", "urn:business-engineer:concept:counting-boundary" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:115", "urn:business-engineer:source-entry:pack:159" ], "instruments": [ "urn:business-engineer:instrument:capital-print", "urn:business-engineer:instrument:reconciliation" ], "modes": [ "urn:business-engineer:mode:print" ] }, { "@id": "urn:business-engineer:model:0116", "@type": "Model", "id": 116, "stableId": "BE-M0116", "name": "Operating and Non-Operating Earnings", "aliases": [ "Hedge the Displacement", "Net Income Has Two Engines", "Read the Sign of the Distortion (Two Engines, Both Ways)" ], "definition": "Separate operating performance from investment marks and other non-operating effects, reconciling positive and negative distortions to reported results.", "keyQuestion": "How much of the bottom line is the operating engine — and how much is a mark that can reverse?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of the bottom line is the operating engine — and how much is a mark that can reverse?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:183", "name": "Strategic Equity Hedge", "definition": "An investment position may offset or amplify weakness in a firm's operations, creating two distinct earnings and exposure channels.", "evidence": "Reconcile operating results, realized returns, unrealized marks and correlated risks.", "falsifier": "Low economic offset in stressed scenarios weakens the hedge interpretation.", "limits": "A reported gain does not necessarily supply cash or make the operating business healthy.", "mappingKind": "scopedVariant" }, { "sourceId": "pack:228", "name": "Bidirectional Earnings Reconciliation", "definition": "Remove or explain both positive and negative non-operating distortions when assessing operating performance.", "evidence": "Bridge reported results to the selected operating measure with symmetric inclusion rules.", "falsifier": "Selective treatment of gains and losses invalidates the comparison.", "limits": "Noncash operating costs such as stock compensation still have economic consequences.", "mappingKind": "equivalentMechanism" } ], "sourceIds": [ "base:116", "pack:183", "pack:228" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:116", "urn:business-engineer:source-entry:pack:183", "urn:business-engineer:source-entry:pack:228" ], "instruments": [ "urn:business-engineer:instrument:capital-print" ], "modes": [ "urn:business-engineer:mode:print" ] }, { "@id": "urn:business-engineer:model:0117", "@type": "Model", "id": 117, "stableId": "BE-M0117", "name": "Expensed vs Capitalized (The Control Group)", "definition": "Distinguish costs recognized as expenses from expenditures capitalized and recognized over time; neither accounting treatment removes the economic cost.", "keyQuestion": "What does the non-builder's position reveal about what the builders are paying for — and where did its risk go instead?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What does the non-builder's position reveal about what the builders are paying for — and where did its risk go instead?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Renting can reduce direct owned-asset exposure but does not remove financing risk. Leases, minimum commitments, guarantees, counterparty failure and loss of access may remain.", "calibration": "Renting can reduce direct owned-asset exposure but does not remove financing risk. Leases, minimum commitments, guarantees, counterparty failure and loss of access may remain.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:117" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:rent", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:117" ] }, { "@id": "urn:business-engineer:model:0118", "@type": "Model", "id": 118, "stableId": "BE-M0118", "name": "Pre-Funding Makes the Near Term Sticky", "definition": "Prefunding can lengthen a project's runway and make later spending more likely, but commitments, restrictions and cancellation rights determine durability.", "keyQuestion": "Is this period's spend already funded and sticky — and am I watching guidance, where the actual decision will show first?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this period's spend already funded and sticky — and am I watching guidance, where the actual decision will show first?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Prefunding provides liquidity; it does not require the money to be spent. Stickiness depends on contracts, sunk costs, cancellation penalties, strategic incentives and alternative use of funds. Guidance is an indicator, not a guaranteed one-year lead.", "calibration": "Prefunding provides liquidity; it does not require the money to be spent. Stickiness depends on contracts, sunk costs, cancellation penalties, strategic incentives and alternative use of funds. Guidance is an indicator, not a guaranteed one-year lead.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:118" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:118" ] }, { "@id": "urn:business-engineer:model:0119", "@type": "Model", "id": 119, "stableId": "BE-M0119", "name": "Deferral vs Transfer", "definition": "Deferring an obligation changes timing; transferring risk changes who bears it. Trace recourse, guarantees and retained exposure to distinguish the two.", "keyQuestion": "Does this obligation eventually arrive on the balance sheet — or has the risk been moved somewhere it will never be consolidated?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this obligation eventually arrive on the balance sheet — or has the risk been moved somewhere it will never be consolidated?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Accounting non-consolidation does not prove economic risk transfer. Separate recognition timing, guarantees, recourse, first-loss exposure, legal transfer and residual incentives.", "calibration": "Accounting non-consolidation does not prove economic risk transfer. Separate recognition timing, guarantees, recourse, first-loss exposure, legal transfer and residual incentives.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:119" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:119" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0120", "@type": "Model", "id": 120, "stableId": "BE-M0120", "name": "The Marginal Channel", "aliases": [ "Capex Is a Placement Decision (The Six Tiers)" ], "definition": "Identify the next unit of funding and its terms, rather than inferring marginal financing conditions from the average historical capital mix.", "keyQuestion": "How is the marginal dollar financed — and is that different from how the average dollar was?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How is the marginal dollar financed — and is that different from how the average dollar was?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Compare marginal funding using aligned periods and definitions. Faster off-book growth is a signal to inspect, not proof of concealment or a specific future cash burden.", "calibration": "Compare marginal funding using aligned periods and definitions. Faster off-book growth is a signal to inspect, not proof of concealment or a specific future cash burden.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:169", "name": "Marginal Funding Visibility", "definition": "Assess which financing source funds the next commitment and how visible its terms and retained exposure are.", "evidence": "List the seven financing categories named in the source and document terms, recourse and disclosure gaps.", "falsifier": "A transparent marginal financing path can refute a claimed opaque funding dependence.", "limits": "The source says six tiers but lists seven; this is a visibility checklist, not a universal rank.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:120", "pack:169" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counting-boundary" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:120", "urn:business-engineer:source-entry:pack:169" ], "instruments": [ "urn:business-engineer:instrument:financing", "urn:business-engineer:instrument:reconciliation" ] }, { "@id": "urn:business-engineer:model:0121", "@type": "Model", "id": 121, "stableId": "BE-M0121", "name": "The Credit Floor", "definition": "Credit quality and contractual support can determine financing access and cost; there is no universal ratings cutoff or guaranteed credit floor.", "keyQuestion": "Where does investment grade end in this structure — and is anything being built to pretend it extends further?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where does investment grade end in this structure — and is anything being built to pretend it extends further?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Investment grade is not a universal financing boundary. Credit availability depends on cash flows, collateral, guarantees, covenants, pricing, liquidity and lender appetite.", "calibration": "Investment grade is not a universal financing boundary. Credit availability depends on cash flows, collateral, guarantees, covenants, pricing, liquidity and lender appetite.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:121" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:121" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0122", "@type": "Model", "id": 122, "stableId": "BE-M0122", "name": "The Amplifier, Not the Bubble", "definition": "Financing can amplify shocks through leverage, collateral and refinancing needs; it is one possible mechanism in a broader demand and capital system.", "keyQuestion": "Am I measuring the probability of the shock — or the amplification installed for whenever the shock arrives?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I measuring the probability of the shock — or the amplification installed for whenever the shock arrives?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Treat financing structure as an amplifier conditional on a shock. Demand, interest rates, refinancing access, collateral repricing and operational failure can all be shocks. No supplied calibration establishes a composite ceiling or pre-break probability.", "calibration": "Treat financing structure as an amplifier conditional on a shock. Demand, interest rates, refinancing access, collateral repricing and operational failure can all be shocks. No supplied calibration establishes a composite ceiling or pre-break probability.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:122" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:122" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0123", "@type": "Model", "id": 123, "stableId": "BE-M0123", "name": "The Layer Map Is Not the Credit Map", "definition": "A value-chain layer map does not reveal credit exposure. Build a separate map of contracts, guarantees, funding and counterparties.", "keyQuestion": "Am I mapping where value lands or where losses travel — and have I located the joints where the two maps touch?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I mapping where value lands or where losses travel — and have I located the joints where the two maps touch?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Map actual contractual, financing and operational links. Horizontal and vertical are visualization conventions; losses can also propagate through shared inputs, sales dependencies and common asset holdings.", "calibration": "Map actual contractual, financing and operational links. Horizontal and vertical are visualization conventions; losses can also propagate through shared inputs, sales dependencies and common asset holdings.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:123" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:123" ], "instruments": [ "urn:business-engineer:instrument:season-map" ], "modes": [ "urn:business-engineer:mode:season" ] }, { "@id": "urn:business-engineer:model:0124", "@type": "Model", "id": 124, "stableId": "BE-M0124", "name": "Contractual Shock Propagation", "aliases": [ "It Breaks Upward" ], "definition": "Trace how a shock propagates through contractual exposures; upward propagation is a case-specific hypothesis, not a required direction.", "keyQuestion": "Where is the weakest counterparty in this structure — and what would its failure teach before anything expensive breaks?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where is the weakest counterparty in this structure — and what would its failure teach before anything expensive breaks?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Weak counterparties can reveal stress early, but contagion can begin at any node, including a major platform, lender or shared infrastructure provider. Follow exposure direction and capacity to absorb loss; do not impose bottom-up causality.", "calibration": "Weak counterparties can reveal stress early, but contagion can begin at any node, including a major platform, lender or shared infrastructure provider. Follow exposure direction and capacity to absorb loss; do not impose bottom-up causality.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:124" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:124" ] }, { "@id": "urn:business-engineer:model:0125", "@type": "Model", "id": 125, "stableId": "BE-M0125", "name": "The Sequencing Bet", "definition": "Test whether funding, construction, customer adoption and cash receipts arrive in a sequence the business can survive.", "keyQuestion": "Which comes first here — the proof of monetization or the refinancing requirement — and what happens in each order?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which comes first here — the proof of monetization or the refinancing requirement — and what happens in each order?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Monetization before maturity can improve refinancing prospects but does not remove debt maturities or guarantee access. Interest rates, liquidity, lender appetite and collateral still matter.", "calibration": "Monetization before maturity can improve refinancing prospects but does not remove debt maturities or guarantee access. Interest rates, liquidity, lender appetite and collateral still matter.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:125" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counting-boundary" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:125" ] }, { "@id": "urn:business-engineer:model:0126", "@type": "Model", "id": 126, "stableId": "BE-M0126", "name": "The Wrapper Trade", "definition": "A financing wrapper can redistribute claims, maturity and risk without changing the underlying asset's operating productivity.", "keyQuestion": "Whose credit is actually being traded here — the issuer's, or the entity whose obligations it wrapped?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Whose credit is actually being traded here — the issuer's, or the entity whose obligations it wrapped?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:126" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:126" ] }, { "@id": "urn:business-engineer:model:0127", "@type": "Model", "id": 127, "stableId": "BE-M0127", "name": "Downstream Incidence (The Bill for the Build)", "aliases": [ "Incidence Runs Opposite at the Two Ends" ], "definition": "Trace who ultimately bears a cost or captures a benefit through prices, contracts, substitutes and bargaining power, rather than only locating the initial payer.", "keyQuestion": "Who is paying for this buildout without participating in it — and through which shared input does the bill arrive?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who is paying for this buildout without participating in it — and through which shared input does the bill arrive?", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:166", "name": "Reverse Incidence Through the Stack", "definition": "The party initially receiving or paying cash may pass costs or benefits to other layers through contracts and prices.", "evidence": "Follow contractual adjustments and pass-through in both directions, with elasticities where estimable.", "falsifier": "Fixed terms or strong alternatives can block the predicted transmission.", "limits": "Incidence does not have a universal direction.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:127", "pack:166" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:counter-model", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:127", "urn:business-engineer:source-entry:pack:166" ], "instruments": [ "urn:business-engineer:instrument:incidence" ] }, { "@id": "urn:business-engineer:model:0128", "@type": "Model", "id": 128, "stableId": "BE-M0128", "name": "Price Is Not Capacity", "definition": "Distinguish a quoted price from physically and contractually available capacity at the place, time and quality required.", "keyQuestion": "How much of this spending growth buys additional capacity — and how much just pays the new price of the old capacity?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D05" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of this spending growth buys additional capacity — and how much just pays the new price of the old capacity?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:128" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:128" ] }, { "@id": "urn:business-engineer:model:0129", "@type": "Model", "id": 129, "stableId": "BE-M0129", "name": "Toll Booths vs Tourists", "aliases": [ "The Access Rent" ], "definition": "A firm may earn durable rents from controlling a scarce junction, but access rents weaken when substitutes, capacity or bargaining conditions change.", "keyQuestion": "Does this company price the constraint or pay it — and can anyone upstream or downstream internalize its position?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D03", "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this company price the constraint or pay it — and can anyone upstream or downstream internalize its position?", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "A bottleneck creates potential bargaining power only when the firm controls access and can capture rents. Substitution, contracts, regulation and customer integration may prevent monetization.", "calibration": "A bottleneck creates potential bargaining power only when the firm controls access and can capture rents. Substitution, contracts, regulation and customer integration may prevent monetization.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:258", "name": "Access Rent", "definition": "A rent based on scarce access can weaken or migrate when the constraint opens or an alternative route becomes viable.", "evidence": "Track access scarcity, switching options and retained margins after capacity or access changes.", "falsifier": "Sustained differentiated value can preserve rent after the original scarcity ends.", "limits": "Scarcity removal does not determine where all value will move.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:129", "pack:258" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:junction", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:129", "urn:business-engineer:source-entry:pack:258" ] }, { "@id": "urn:business-engineer:model:0130", "@type": "Model", "id": 130, "stableId": "BE-M0130", "name": "The Rotating Bottleneck", "aliases": [ "Networking Inversion" ], "definition": "The binding bottleneck can move as supply, efficiency, financing and adoption change; verify where the constraint binds at each decision horizon.", "keyQuestion": "What binds today, what binds next — and is more than one constraint binding at once?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D06" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What binds today, what binds next — and is more than one constraint binding at once?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:200", "name": "Moving Compute Bottleneck", "definition": "The limiting resource in an AI system can shift among compute, memory, interconnect, data access, power and demand.", "evidence": "Profile the workload and test throughput after relieving the suspected constraint.", "falsifier": "No performance gain or a different binding resource weakens the diagnosis.", "limits": "Vendor specifications do not establish the bottleneck in the deployed workload.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:130", "pack:200" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:130", "urn:business-engineer:source-entry:pack:200" ], "instruments": [ "urn:business-engineer:instrument:season-map" ], "modes": [ "urn:business-engineer:mode:season" ] }, { "@id": "urn:business-engineer:model:0131", "@type": "Model", "id": 131, "stableId": "BE-M0131", "name": "Asynchronous Clocks", "aliases": [ "The Four Clocks" ], "definition": "Analyze asynchronous physical, financial, efficiency and adoption clocks, adding political objectives and permissions when state action materially changes the system.", "keyQuestion": "Which clock is this datapoint on — and which clock is the argument I'm evaluating secretly assuming?", "form": "framework", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which clock is this datapoint on — and which clock is the argument I'm evaluating secretly assuming?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "The four clocks are useful categories, not fixed speeds. Physical plans can be cancelled at a cost, credit may be committed for years, and efficiency or adoption can stall. Measure actual horizons and coupling.", "calibration": "The four clocks are useful categories, not fixed speeds. Physical plans can be cancelled at a cost, credit may be committed for years, and efficiency or adoption can stall. Measure actual horizons and coupling.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:131" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption", "urn:business-engineer:clock:political" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:131" ], "instruments": [ "urn:business-engineer:instrument:season-map" ], "modes": [ "urn:business-engineer:mode:season", "urn:business-engineer:mode:geopolitics" ] }, { "@id": "urn:business-engineer:model:0132", "@type": "Model", "id": 132, "stableId": "BE-M0132", "name": "Demand Has a Shape, Not Just a Size", "aliases": [ "Node-by-Node Correction" ], "definition": "Map demand and investment by node, actor and time; a local correction does not by itself diagnose the condition of the entire buildout.", "keyQuestion": "If demand keeps its size but changes its shape, which committed positions are stranded — and which quietly become the destination?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "If demand keeps its size but changes its shape, which committed positions are stranded — and which quietly become the destination?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:137", "name": "Node-by-Node Correction", "definition": "A buildout can reprice at different nodes and times as local demand, capacity and financing diverge.", "evidence": "Compare node-specific utilization, prices, commitments and funding before and after a drawdown.", "falsifier": "Synchronous deterioration across independent nodes supports a system-wide shock instead.", "limits": "Local and systemic corrections can coexist; a bubble question is not inherently invalid.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:132", "pack:137" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:132", "urn:business-engineer:source-entry:pack:137" ], "instruments": [ "urn:business-engineer:instrument:capital-print", "urn:business-engineer:instrument:season-map" ], "modes": [ "urn:business-engineer:mode:season" ] }, { "@id": "urn:business-engineer:model:0133", "@type": "Model", "id": 133, "stableId": "BE-M0133", "name": "Split by Clock, Not by Category", "definition": "Separate exposures by the clocks that determine their adjustment, cash flow and repricing rather than assuming the whole stack moves together.", "keyQuestion": "How does this spending split by asset clock — and is the financing matched to the clock it's actually secured against?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How does this spending split by asset clock — and is the financing matched to the clock it's actually secured against?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "calibration": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:133" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:institution", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:133" ], "instruments": [ "urn:business-engineer:instrument:season-map" ] }, { "@id": "urn:business-engineer:model:0134", "@type": "Model", "id": 134, "stableId": "BE-M0134", "name": "Efficiency, Demand and Value Incidence", "aliases": [ "Efficiency Expands the Market (The Efficiency Paradox)", "Efficiency Is Obsolescence From the Collateral Side", "Same Tide, Different Beaches", "The Deflation Paradox" ], "definition": "Efficiency can lower unit costs, alter demand and redistribute value; total spending and installed-asset returns depend on elasticity, pass-through and vintage exposure.", "keyQuestion": "Does this efficiency gain shrink the market or expand it — and which specific installed assets does it reprice on the way?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D05", "urn:business-engineer:domain:D03" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this efficiency gain shrink the market or expand it — and which specific installed assets does it reprice on the way?", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Falling unit prices can increase quantity while total spending rises or falls. Spending rises only when the relevant quantity response outweighs the price decline. Separate workload demand, resource demand, supplier revenue and asset-vintage value; obsolescence is not automatic.", "calibration": "Falling unit prices can increase quantity while total spending rises or falls. Spending rises only when the relevant quantity response outweighs the price decline. Separate workload demand, resource demand, supplier revenue and asset-vintage value; obsolescence is not automatic.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:150", "name": "Efficiency Incidence", "definition": "Efficiency gains are divided among users, suppliers and intermediaries according to competition, contracts and elasticity.", "evidence": "Measure cost decline, price pass-through, volume and margins across the affected layers.", "falsifier": "Falling unit costs without downstream price or volume change weakens a claimed demand expansion.", "limits": "Total spending can rise or fall; aggregate benefit does not protect every asset vintage.", "mappingKind": "scopedVariant" }, { "sourceId": "pack:171", "name": "Efficiency and Asset Vintage", "definition": "Efficiency can reduce older assets' earning power and collateral value, transmitting through leverage, covenants and refinancing to the vehicle's creditors.", "evidence": "Compare vintage utilization and residual values with tenant contracts, loan-to-value terms, covenants, maturities, guarantees and recourse.", "falsifier": "Durable contracted cash flows, low leverage or adequate replacement collateral can block the predicted credit transmission.", "limits": "Efficiency benefits do not guarantee impairment or creditor loss; the contract and funding structure determine who bears repricing.", "mappingKind": "scopedVariant" }, { "sourceId": "pack:187", "name": "Efficiency and Spending Elasticity", "definition": "Lower cost per unit may expand usage, but total spending depends on how strongly demand responds and where savings are retained.", "evidence": "Estimate price changes, volume response and contribution margin with alternative elasticity scenarios.", "falsifier": "Weak volume response refutes a claim that efficiency necessarily increases spending.", "limits": "Separate technical efficiency from customer price and from total market expenditure.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:134", "pack:150", "pack:171", "pack:187" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:institution" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:134", "urn:business-engineer:source-entry:pack:150", "urn:business-engineer:source-entry:pack:171", "urn:business-engineer:source-entry:pack:187" ] }, { "@id": "urn:business-engineer:model:0135", "@type": "Model", "id": 135, "stableId": "BE-M0135", "name": "Own the Junctions, Rent the Ends (The Property Line)", "aliases": [ "Rent the Agent, Own the Rail (AGaaS)", "The Owned/Rented Barbell (The Alpha-Writing Sort)" ], "definition": "Decide which important junctions, knowledge and controls to own or contractually govern and which endpoints to rent, based on economics, rights and exit feasibility.", "keyQuestion": "Of everything this system touches, what compounds — and does it compound on my side of the property line or the vendor's?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07", "urn:business-engineer:domain:D03", "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D02" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Of everything this system touches, what compounds — and does it compound on my side of the property line or the vendor's?", "evidence": "Inspect actual artifacts, rights, operating permissions, handovers and a priced alternative execution path; interviews alone do not establish control.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Own or control the junctions when their strategic value exceeds their costs and risks. Some endpoints compound, some junctions commoditize, and contractual rights may suffice. Make the boundary decision per workload.", "calibration": "Own or control the junctions when their strategic value exceeds their costs and risks. Some endpoints compound, some junctions commoditize, and contractual rights may suffice. Make the boundary decision per workload.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "applications": [ { "sourceId": "pack:177", "name": "Commerce Property Line", "definition": "Decide which transaction authority, customer relationship and operational knowledge should remain under a business's control as interfaces change.", "evidence": "Map ownership, permission and exit at discovery, selection, purchase and post-purchase stages.", "falsifier": "Transferable customers and reliable alternative execution weaken a claimed captured junction.", "limits": "Control can be contractual; owning every layer is not required.", "mappingKind": "scopedVariant" }, { "sourceId": "pack:192", "name": "Owned and Rented Architecture", "definition": "Combine controlled durable assets with rented capabilities when this improves economics, adaptability and bargaining options.", "evidence": "Compare title, operating rights, maintenance, switching and alternative-execution costs for each layer.", "falsifier": "Higher total cost or brittle integration can defeat the proposed ownership mix.", "limits": "Open weights do not automatically provide IP ownership or freedom from dependency.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "base:135", "pack:177", "pack:192" ], "usesConcept": [ "urn:business-engineer:concept:junction", "urn:business-engineer:concept:property-line", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:135", "urn:business-engineer:source-entry:pack:177", "urn:business-engineer:source-entry:pack:192" ], "instruments": [ "urn:business-engineer:instrument:capture" ], "modes": [ "urn:business-engineer:mode:capture" ] }, { "@id": "urn:business-engineer:model:0136", "@type": "Model", "id": 136, "stableId": "BE-M0136", "name": "Clear Title (KEPT / PARTIAL / CAPTURED)", "definition": "Assess retained rights, usable exports, semantic completeness, alternative execution and migration cost separately; operational exit readiness is not a legal title opinion.", "keyQuestion": "If this engagement ended tomorrow, what would exit actually cost, artifact by artifact — a config change, a project, or a rebuild?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "If this engagement ended tomorrow, what would exit actually cost, artifact by artifact — a config change, a project, or a rebuild?", "evidence": "Inspect actual artifacts, rights, operating permissions, handovers and a priced alternative execution path; interviews alone do not establish control.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "decision": "Choose, revise or reject an intervention only after applying the model to the stated actor, unit, alternatives and horizon.", "limits": "Separate legal rights, access to artifacts, semantic completeness, practical portability and economic switching cost. KEPT/PARTIAL/CAPTURED are operational exit grades; they do not establish legal title. Price and exercise the exit path.", "calibration": "Separate legal rights, access to artifacts, semantic completeness, practical portability and economic switching cost. KEPT/PARTIAL/CAPTURED are operational exit grades; they do not establish legal title. Price and exercise the exit path.", "origin": "Full user-supplied 136-model source, received September 9, 2026. Original wording preserved for provenance; current calibration governs application.", "sourceIds": [ "base:136" ], "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:base:136" ], "instruments": [ "urn:business-engineer:instrument:capture", "urn:business-engineer:instrument:verified", "urn:business-engineer:instrument:priced-exit" ], "modes": [ "urn:business-engineer:mode:capture", "urn:business-engineer:mode:buyer" ] }, { "@id": "urn:business-engineer:model:0137", "@type": "Model", "id": 137, "stableId": "BE-M0137", "name": "Technology Constellation", "definition": "A technology becomes economically transformative when complementary energy, materials, production, transport, capital and organizational capabilities reinforce one another. Map reciprocal enabling relationships rather than forcing a single invention-first story.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Explain an industrial transition or identify which complement must develop before an AI capability can diffuse.", "evidence": "Identify what each complement makes cheaper, faster or feasible; date the enabling changes; compare places with the invention but without its complements.", "falsifier": "The claimed complement is absent in successful cases, or adoption follows another mechanism such as demand, institutions or distribution.", "decision": "Invest in or partner around the missing complement that limits a specific adoption path.", "limits": "A constellation is a causal hypothesis, not a universal sequence. Do not infer the chronology of coal, railways, iron, steel, naval power or oil from the diagram; verify it for each historical case.", "calibration": "A constellation is a causal hypothesis, not a universal sequence. Do not infer the chronology of coal, railways, iron, steel, naval power or oil from the diagram; verify it for each historical case.", "origin": "Synthesis from the September 8, 2026 technogeopolitics discussion; linked to the general-purpose-technology literature, without claiming this formulation is validated by it.", "sourceIds": [ "expansion:137" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption", "urn:business-engineer:clock:political" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:137" ], "instruments": [ "urn:business-engineer:instrument:junction" ] }, { "@id": "urn:business-engineer:model:0138", "@type": "Model", "id": 138, "stableId": "BE-M0138", "name": "Capability-to-Power Conversion", "aliases": [ "The Cascade Is the Rotation" ], "definition": "Resource access creates potential. Production competence, reliable energy, logistics, finance, skilled institutions and deployment capacity determine whether potential becomes sustained economic or strategic power. Every conversion has losses and delays.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D02" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Compare countries or firms that possess similar inputs but obtain different strategic outcomes.", "evidence": "Measure usable throughput, delivered cost, supply reliability, productive utilization, deployment reach and resilience. Locate the stage where an advantage stops translating.", "falsifier": "Input ownership alone predicts durable power better than conversion capability, or an omitted alliance or institutional variable explains the observed advantage.", "decision": "Strengthen the weakest conversion stage before acquiring more of an already abundant input.", "limits": "Economic capability does not mechanically produce military dominance, legitimacy or rule-making authority. Keep those outcomes separate and explain the intervening institutions.", "calibration": "Economic capability does not mechanically produce military dominance, legitimacy or rule-making authority. Keep those outcomes separate and explain the intervening institutions.", "origin": "Synthesis from the September 8, 2026 discussion of energy, industry, logistics and changing world power.", "applications": [ { "sourceId": "pack:140", "name": "Capability-to-Power Conversion", "definition": "Technologies can shift industrial control and strategic power when complementary production, institutions and permissions convert capability into enforceable advantage.", "evidence": "Trace each conversion step and compare settings with capability but different control.", "falsifier": "Capability without enforceable leverage weakens the claimed conversion.", "limits": "A conceptual cascade is not a universal chronological sequence.", "mappingKind": "equivalentMechanism" } ], "sourceIds": [ "expansion:138", "pack:140" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:institution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:138", "urn:business-engineer:source-entry:pack:140" ], "instruments": [ "urn:business-engineer:instrument:junction" ] }, { "@id": "urn:business-engineer:model:0139", "@type": "Model", "id": 139, "stableId": "BE-M0139", "name": "Legitimacy and Enforcement", "definition": "An institutional order combines material capacity to enforce rules with participants’ reasons to accept them. Enforcement can sustain an unpopular order for a time; acceptance can reduce the cost of enforcement. Both feed back into resources and coalitions.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Analyze the resilience of a geopolitical order, platform governance regime or industry standard.", "evidence": "Separate formal rules, actual compliance, enforcement capacity, perceived benefits, coalition cohesion and credible exit alternatives.", "falsifier": "Changes in legitimacy or enforcement do not alter compliance, or material incentives alone explain the pattern more convincingly.", "decision": "Identify whether the binding problem is enforcement, consent, distribution of benefits or a credible alternative institution.", "limits": "Do not infer that a power transition automatically ends international law or institutional legitimacy. Treat historical analogies as questions, not settled explanations.", "calibration": "Do not infer that a power transition automatically ends international law or institutional legitimacy. Treat historical analogies as questions, not settled explanations.", "origin": "Synthesis from the September 8, 2026 conversations about international order and technogeopolitics.", "sourceIds": [ "expansion:139" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:institution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:139" ], "instruments": [ "urn:business-engineer:instrument:junction" ] }, { "@id": "urn:business-engineer:model:0140", "@type": "Model", "id": 140, "stableId": "BE-M0140", "name": "Strategic Dependence Asymmetry", "aliases": [ "The Dependency Is a Variable, Not a Verdict", "The Rented Front Door, One Layer Down" ], "definition": "Dependence becomes leverage when one side can substitute, wait or absorb disruption more easily than the other. Supplier concentration matters through replacement time, usable alternatives, inventories, switching cost and exposure on both sides.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D03", "urn:business-engineer:domain:D02" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Assess strategic autonomy, vendor dependency, supply-chain leverage or bargaining power.", "evidence": "For both parties, estimate replacement time, disruption loss over that time, inventories, alternative capacity and the credibility of threats.", "falsifier": "The apparently dependent party switches cheaply, the supplier suffers greater losses, or other actors can neutralize the pressure.", "decision": "Buy redundancy or switching capability where the asymmetry is consequential; avoid paying for nominal domestic ownership that does not improve usable alternatives.", "limits": "Nationality, ownership and control are different variables. Resilience can come from diversified interdependence rather than complete self-sufficiency.", "calibration": "Nationality, ownership and control are different variables. Resilience can come from diversified interdependence rather than complete self-sufficiency.", "origin": "Synthesis from sovereign-AI terminology, anti-lock-in and technogeopolitics discussions in August–September 2026.", "applications": [ { "sourceId": "pack:184", "name": "Strategic Dependence Asymmetry", "definition": "Compare how badly each party needs the relationship and how cheaply each can replace it.", "evidence": "Price alternatives, transition time, concentration and critical dependencies on both sides.", "falsifier": "Comparable credible alternatives weaken an asymmetric-power diagnosis.", "limits": "Dependency varies by workload and can change after integration.", "mappingKind": "equivalentMechanism" }, { "sourceId": "pack:185", "name": "Channel Dependence Asymmetry", "definition": "A distribution partner can gain bargaining power when a supplier depends more on its channel than it depends on that supplier.", "evidence": "Compare customer reach, substitution, direct access and switching economics for both parties.", "falsifier": "Strong direct demand or indispensable supply can overturn the channel-power thesis.", "limits": "Distribution scale alone does not establish control.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:140", "pack:184", "pack:185" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:140", "urn:business-engineer:source-entry:pack:184", "urn:business-engineer:source-entry:pack:185" ], "instruments": [ "urn:business-engineer:instrument:incidence" ] }, { "@id": "urn:business-engineer:model:0141", "@type": "Model", "id": 141, "stableId": "BE-M0141", "name": "Power Transition Lag", "aliases": [ "The Three-Generation Lag and the Domestic Bill" ], "definition": "A new productive system can emerge before institutions, financing structures, skills and strategic doctrine adapt. The incumbent’s installed base may provide cash and reach while also creating commitments that slow adaptation.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Assess transitions between industrial paradigms or between incumbent and AI-native operating models.", "evidence": "Track capability adoption and institutional adaptation separately; identify which legacy assets are reusable and which become constraints.", "falsifier": "The incumbent repurposes its assets faster than challengers build replacements, or the new capability fails to become economically significant.", "decision": "Preserve valuable inherited assets while changing the commitments that obstruct the new system.", "limits": "A lead in a technology does not date or guarantee a geopolitical succession. Fixed 30–50-year cycles are not forecasting laws.", "calibration": "A lead in a technology does not date or guarantee a geopolitical succession. Fixed 30–50-year cycles are not forecasting laws.", "origin": "Synthesis from technogeopolitics and technology-supercycle discussions; an analytical extension rather than a historical chronology.", "applications": [ { "sourceId": "pack:153", "name": "Power Transition Lag", "definition": "New industrial capabilities may take time to alter institutions, strategic power and domestic economic burdens.", "evidence": "Date capability, adoption, institutional response and distributional effects separately.", "falsifier": "Concurrent change or reversed sequencing challenges a proposed lag mechanism.", "limits": "No fixed three-generation interval is supported by the source.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:141", "pack:153" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:institution" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption", "urn:business-engineer:clock:political" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:141", "urn:business-engineer:source-entry:pack:153" ], "instruments": [ "urn:business-engineer:instrument:junction" ] }, { "@id": "urn:business-engineer:model:0142", "@type": "Model", "id": 142, "stableId": "BE-M0142", "name": "Computable Operating Model", "definition": "Translate business concepts, desired outcomes, roles, decision rights, policies, process logic and exceptions into a maintained canonical representation. The representation makes organizational meaning inspectable before it is connected to execution.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "framework", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Scope enterprise AI work when operational knowledge is scattered across documents, systems, diagrams and people.", "evidence": "Trace representative decisions from source evidence to entities, policies, accountable owners and exceptions; have process owners validate the resulting interpretation.", "falsifier": "The model cannot represent material exceptions, owners cannot agree on meaning, or maintaining it costs more than the coordination it removes.", "decision": "Model a bounded process and its decision rights first, then connect the approved specification to an execution design.", "limits": "A representation is neither executable software nor proof of organizational agreement. Process-mining outputs are useful inputs, not a requirement to rebuild process mining.", "calibration": "A representation is neither executable software nor proof of organizational agreement. Process-mining outputs are useful inputs, not a requirement to rebuild process mining.", "origin": "User terminology from the WordLift computable-operating-model and Fixpoint conversations, August–September 2026.", "sourceIds": [ "expansion:142" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:142" ] }, { "@id": "urn:business-engineer:model:0143", "@type": "Model", "id": 143, "stableId": "BE-M0143", "name": "Process Specification and Runtime", "definition": "Separate the declarative process contract from the mechanism that executes it. A CPO records capabilities, boundaries, expected behavior and acceptance conditions; a runtime chooses and performs implementation steps within those constraints.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07", "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Design a process product intended to work across models, agents or orchestration environments.", "evidence": "Map every required business invariant to a runtime control and an observable acceptance test. Run representative cases in more than one implementation when portability is claimed.", "falsifier": "Core business semantics depend on one runtime’s hidden state, or the specification cannot distinguish compliant from unacceptable outcomes.", "decision": "Stabilize the process contract and test alternative implementations against the same business requirements.", "limits": "CPO retains the user’s term without inventing its acronym expansion. Declarative design permits implementation freedom; it does not guarantee enforcement, reliability or zero-cost portability.", "calibration": "CPO retains the user’s term without inventing its acronym expansion. Declarative design permits implementation freedom; it does not guarantee enforcement, reliability or zero-cost portability.", "origin": "User refinement in Fixpoint discussions, September 3–8, 2026; design intent, not a claim of a completed interoperable standard.", "sourceIds": [ "expansion:143" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:143" ] }, { "@id": "urn:business-engineer:model:0144", "@type": "Model", "id": 144, "stableId": "BE-M0144", "name": "Reference Library and Customer Delta", "definition": "Separate reusable process knowledge from the customer-specific rules, systems, terminology and exceptions that adapt it. Reuse can reduce deployment work only when the reference fits the new case and the delta remains governable.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Design a repeatable enterprise offering around pre-seeded recipes and customer-owned process adaptations.", "evidence": "Record effort spent on reusable components, adaptation, integration, validation and ongoing maintenance for each deployment; record ownership and permission to reuse each artifact.", "falsifier": "Customer deltas repeatedly overwrite the reference, reuse requires confidential customer knowledge, or adaptation effort does not decline.", "decision": "Keep a versioned shared reference and a separately owned customer delta; use measured cohorts to decide where to standardize.", "limits": "The 80/20 split is a proposed design target, not a benchmark or measured outcome. Configuration size is not a proxy for effort, risk or value.", "calibration": "The 80/20 split is a proposed design target, not a benchmark or measured outcome. Configuration size is not a proxy for effort, risk or value.", "origin": "User distinction between platform-owned Recipe Library and client-owned Process Model, August–September 2026.", "sourceIds": [ "expansion:144" ], "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:144" ] }, { "@id": "urn:business-engineer:model:0145", "@type": "Model", "id": 145, "stableId": "BE-M0145", "name": "N+1 Deployment Learning Curve", "definition": "A deployment business becomes more product-like when knowledge from deployment N lowers the normalized effort or improves the outcomes of deployment N+1 without transferring restricted customer data.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate whether a process platform can scale beyond bespoke implementation work.", "evidence": "Compare similar deployments by process complexity, integration burden and risk. Track calendar time, specialist hours, first-pass acceptance, exception rates and recurring support cost.", "falsifier": "Apparent improvement comes only from easier customers, unpaid labor, narrower scope or shifted maintenance costs.", "decision": "Scale the process families with demonstrated transfer; price or decline the work whose complexity remains customer-specific.", "limits": "A falling deployment-time chart alone does not establish a learning curve or a data moat. Normalize case mix and separate one-time delivery from recurring operation.", "calibration": "A falling deployment-time chart alone does not establish a learning curve or a data moat. Normalize case mix and separate one-time delivery from recurring operation.", "origin": "Synthesis of the Fixpoint N+1 deployment, pre-seeded expertise and productizing-the-deployment-layer discussions.", "sourceIds": [ "expansion:145" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:145" ], "instruments": [ "urn:business-engineer:instrument:deploy" ] }, { "@id": "urn:business-engineer:model:0146", "@type": "Model", "id": 146, "stableId": "BE-M0146", "name": "Semantic-to-Action Ladder", "definition": "Machine-readable terminology helps identify meaning; entities and relationships supply context; capability and policy descriptions constrain available actions; authenticated execution changes state; evidence shows what actually happened. Each transition requires an explicit interface.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Analyze agentic commerce or distinguish knowledge-graph value from workflow execution capability.", "evidence": "Trace one user intent through term resolution, entity grounding, applicable policy, authorized action, external state change and an observed outcome.", "falsifier": "Improved semantic coverage does not improve task success, or failures occur at unrelated execution or commercial constraints.", "decision": "Invest in the specific missing transition rather than treating additional markup as a complete agentic workflow.", "limits": "RDF, JSON-LD, schema markup and MCP do not by themselves grant business authority or guarantee transactions. The ladder is an analytical decomposition, not a mandatory software architecture.", "calibration": "RDF, JSON-LD, schema markup and MCP do not by themselves grant business authority or guarantee transactions. The ladder is an analytical decomposition, not a mandatory software architecture.", "origin": "User discussions on lexical graphs, action graphs, declarative APIs and WordLift semantic infrastructure, April–September 2026.", "sourceIds": [ "expansion:146" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:146" ] }, { "@id": "urn:business-engineer:model:0147", "@type": "Model", "id": 147, "stableId": "BE-M0147", "name": "Action Boundary Map", "definition": "Assign each expected action to an operating boundary: owned, partner handoff, informational only or not applicable. Then identify the actor authorized to act, prerequisites, destination, observable result and escalation route.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Review a machine-readable business capability or agent journey before treating it as executable.", "evidence": "Use current capability evidence, operating-owner confirmation, contracts or documented handoffs, permission checks and observed execution tests.", "falsifier": "The asserted owner cannot perform the action, a handoff destination is unverified, or a description is being mistaken for operational capability.", "decision": "Expose only the supported boundary and fix the missing ownership, handoff or execution evidence.", "limits": "User intent about a desired capability must not rewrite evidence-based readiness. Informational content can be valuable without being an executable action.", "calibration": "User intent about a desired capability must not rewrite evidence-based readiness. Informational content can be valuable without being an executable action.", "origin": "Exact boundary vocabulary from the September 4, 2026 Terms of Action review request.", "sourceIds": [ "expansion:147" ], "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:147" ], "instruments": [ "urn:business-engineer:instrument:charter" ] }, { "@id": "urn:business-engineer:model:0148", "@type": "Model", "id": 148, "stableId": "BE-M0148", "name": "Portability Is Exercised", "definition": "Portability exists in degrees: contractual rights, complete export, preserved meaning, alternative execution, acceptable performance and affordable migration. Evidence at one degree does not prove the others.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07", "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate a vendor’s neutrality claim, a CPO design or an enterprise exit plan.", "evidence": "Exercise an export/import/replay on representative data and exceptions; price adapters, missing features, retraining, migration labor and downtime.", "falsifier": "The destination cannot reproduce required behavior or the practical exit cost remains comparable to a rebuild.", "decision": "Purchase and rehearse the specific switching option that matters for the workload; record residual dependencies explicitly.", "limits": "Owning a JSON file or using an open protocol is insufficient. Full interchangeability may be uneconomic; a bounded and priced exit can still be valuable.", "calibration": "Owning a JSON file or using an open protocol is insufficient. Full interchangeability may be uneconomic; a bounded and priced exit can still be valuable.", "origin": "Synthesis from CPO portability, Palantir/Databricks anti-lock-in and the Enterprise Capture Test discussions.", "sourceIds": [ "expansion:148" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:148" ], "instruments": [ "urn:business-engineer:instrument:capture", "urn:business-engineer:instrument:priced-exit" ], "modes": [ "urn:business-engineer:mode:capture" ] }, { "@id": "urn:business-engineer:model:0149", "@type": "Model", "id": 149, "stableId": "BE-M0149", "name": "Governance Independence Test", "aliases": [ "The Seat That Grades Never Built" ], "definition": "Governance is more independent when the party defining acceptance, holding evidence and authorizing exceptions can challenge the party optimizing execution. Structural independence depends on decision rights, incentives and access to evidence.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07", "urn:business-engineer:domain:D09" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Design oversight for interchangeable AI runtimes or evaluate a vendor’s assurance claim.", "evidence": "Identify who sets controls, changes tests, reports incidents, approves exceptions, can pause execution and receives commercial rewards.", "falsifier": "The overseer cannot inspect outcomes, alter approvals or escalate failures, or its compensation encourages hiding the same failures as the executor.", "decision": "Separate the necessary decision rights and evidence access; specify the conflicts that remain.", "limits": "A separate dashboard, company or model is not automatically independent. The third-party-CPA analogy describes a role and does not confer audit status or regulatory certification.", "calibration": "A separate dashboard, company or model is not automatically independent. The third-party-CPA analogy describes a role and does not confer audit status or regulatory certification.", "origin": "Synthesis from Fixpoint independent-governance and control-tower framing, September 2026.", "applications": [ { "sourceId": "pack:255", "name": "Independent Governance", "definition": "Separate acceptance authority from delivery incentives sufficiently to make failures visible and actionable.", "evidence": "Inspect reporting lines, veto rights, conflict handling, evaluator access and independent review evidence.", "falsifier": "Overridden findings or builder-controlled acceptance undermine claimed independence.", "limits": "Independence does not require one universal org chart or prohibit all evaluators from ever building systems.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:149", "pack:255" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:control-plane", "urn:business-engineer:concept:independent-evaluation", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:149", "urn:business-engineer:source-entry:pack:255" ], "instruments": [ "urn:business-engineer:instrument:verified", "urn:business-engineer:instrument:suite", "urn:business-engineer:instrument:responsibility-grid" ], "modes": [ "urn:business-engineer:mode:roles" ] }, { "@id": "urn:business-engineer:model:0150", "@type": "Model", "id": 150, "stableId": "BE-M0150", "name": "Regulated Process Wedge", "definition": "A promising entry point is a specific process where costly recurring work, shared structure, an identifiable buyer and feasible delivery intersect. Regulatory load creates work; commercial value depends on who must do it, who pays and which steps can safely be standardized.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Choose an initial enterprise process or compare niches for a process-automation platform.", "evidence": "Assess task frequency and complexity separately; verify budget, authority, repeatability, acceptable error, data access, liability allocation and precise existing alternatives.", "falsifier": "Mandatory work has no accessible budget, customers require mostly bespoke judgment, or a specific incumbent already solves the process economically.", "decision": "Advance a narrow paid design partnership only after delivery and buyer-access gates pass; then compare viable niches by economics and learning potential.", "limits": "Do not turn regulatory density into an automatic attractiveness score. Verify current laws, applicability and implementation dates for any real jurisdiction or process.", "calibration": "Do not turn regulatory density into an automatic attractiveness score. Verify current laws, applicability and implementation dates for any real jurisdiction or process.", "origin": "Synthesis from Fixpoint regulated-process market selection and SI distribution discussions, September 5–6, 2026.", "sourceIds": [ "expansion:150" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:portability" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:150" ] }, { "@id": "urn:business-engineer:model:0151", "@type": "Model", "id": 151, "stableId": "BE-M0151", "name": "Partner Distribution Fit", "definition": "A partner becomes a scalable channel when a proven process aligns with its reachable accounts, seller incentives, delivery capacity and customer relationship. An account list is potential access; active sellers and repeat deployments demonstrate distribution.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Assess SI, consulting or technology partners for a repeatable enterprise offer.", "evidence": "Map eligible accounts to a process owner, named partner sponsor, seller compensation, joint offer, delivery team, procurement path and activated pipeline.", "falsifier": "The partner cannot name an economic buyer, seller incentives conflict, or the first deployments cannot be repeated without founder intervention.", "decision": "Co-design the first use case with the partner that can sell and deliver the next comparable deployment.", "limits": "Zero-to-50 deployments is an ambition, not a forecast. Do not multiply total partner customers by contract value and label the result revenue opportunity.", "calibration": "Zero-to-50 deployments is an ambition, not a forecast. Do not multiply total partner customers by contract value and label the result revenue opportunity.", "origin": "User partner-led market-entry and co-design proposal, September 2026.", "sourceIds": [ "expansion:151" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:151" ] }, { "@id": "urn:business-engineer:model:0152", "@type": "Model", "id": 152, "stableId": "BE-M0152", "name": "Coopetition Boundary", "aliases": [ "The Enterprise Alliance (Opened vs Held)" ], "definition": "A firm can be a channel at one layer, a competitor at another and a possible acquirer later. Map relationships around the exact process, artifact ownership, implementation role, customer access and renewal economics.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03", "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Compare a process platform with SIs, forward-deployed AI companies or broad enterprise platforms.", "evidence": "Build a process-by-provider capability matrix using demonstrated capabilities; record who owns the customer, runtime, reusable knowledge, assurance and recurring contract.", "falsifier": "A presumed complementary partner already delivers the target process with superior economics, or the vendor’s expansion removes the partner’s incentive to distribute it.", "decision": "Draw a written commercial and capability boundary that leaves both sides a reason to repeat the deployment.", "limits": "A general AI platform does not prove strength in a narrow workflow; a narrow specialist is not automatically protected from a generalist. Potential acquisition is a scenario, not a distribution strategy.", "calibration": "A general AI platform does not prove strength in a narrow workflow; a narrow specialist is not automatically protected from a generalist. Potential acquisition is a scenario, not a distribution strategy.", "origin": "Synthesis of Fixpoint versus Wonderful, SI enablement, channel conflict and possible SI acquisition discussions.", "applications": [ { "sourceId": "pack:233", "name": "Alliance and Coopetition Boundary", "definition": "A partner can complement distribution or capabilities while competing for customer control, data or margin.", "evidence": "Map shared incentives, retained assets, competing offerings and exit rights.", "falsifier": "Stable aligned incentives with no material capture risk weaken an adversarial reading.", "limits": "Partnership and competition can coexist; avoid treating all alliances as traps.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:152", "pack:233" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:152", "urn:business-engineer:source-entry:pack:233" ] }, { "@id": "urn:business-engineer:model:0153", "@type": "Model", "id": 153, "stableId": "BE-M0153", "name": "Deployment Responsibility Coverage", "aliases": [ "Deployment Bench Coverage", "The Grid (Watch the Blanks)" ], "definition": "Enterprise delivery needs coverage of process understanding, orchestration, outcome economics and adoption. Process Cartographer, Orchestration Architect, Value Engineer and Enterprise Partner are four specialist contributions; map them to lifecycle work and the five accountability functions without requiring four separate hires.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "framework", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D09" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Assess whether a team can take a bounded process from discovery to reliable operation and renewal.", "evidence": "Inspect active work packages, required handoffs and actual authority; map the four specialist contributions to named accountable owners and independent acceptance.", "falsifier": "One function’s output is not usable by the next, or additional titles do not improve delivery outcomes.", "decision": "Fill the uncovered function or broken handoff before expanding headcount or sales commitments.", "limits": "These are coverage requirements, not four mandatory full-time hires. Preserve Process Cartographer as the user’s role name; do not replace it with Process Expert.", "calibration": "These are coverage requirements, not four mandatory full-time hires. Preserve Process Cartographer as the user’s role name; do not replace it with Process Expert.", "origin": "Exact four-role bench refined in the Fixpoint conversations, August–September 2026.", "applications": [ { "sourceId": "pack:253", "name": "Deployment Responsibility Coverage", "definition": "Map lifecycle work to accountable functions and specialist contributions, making unowned handoffs and conflicts visible.", "evidence": "Use the source-backed five-stage by five-function grid, then assign one accountable owner to each active handoff.", "falsifier": "Repeated failures at nominally owned handoffs show that titles alone did not create operational coverage.", "limits": "The pack's eleven-column variant is underspecified; the eleven-stage extension is explicitly proposed in this ontology.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:153", "pack:253" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:independent-evaluation" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:153", "urn:business-engineer:source-entry:pack:253" ], "instruments": [ "urn:business-engineer:instrument:deploy", "urn:business-engineer:instrument:responsibility-grid" ], "modes": [ "urn:business-engineer:mode:deployment", "urn:business-engineer:mode:roles" ] }, { "@id": "urn:business-engineer:model:0154", "@type": "Model", "id": 154, "stableId": "BE-M0154", "name": "Buyer Permission Path", "definition": "An enterprise purchase crosses several decision rights: budget, business ownership, technical fit, security, legal terms, procurement and production acceptance. Progress at one gate does not imply progress at the others.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Diagnose why strong demos and executive interest fail to become deployed, renewing business.", "evidence": "For each material gate, identify the decision owner, evidence needed, unresolved objection, dependency and expected timing.", "falsifier": "The proposed gating map cannot explain delays, or a different buying route removes the supposed veto.", "decision": "Resolve the gate currently constraining a specific account while preparing evidence for likely downstream gates.", "limits": "Not every enterprise has the same buying process. A PO evidences purchasing progress, not causal ROI, technical acceptance or permission for every production action.", "calibration": "Not every enterprise has the same buying process. A PO evidences purchasing progress, not causal ROI, technical acceptance or permission for every production action.", "origin": "Generalized from enterprise rollout and procurement discussions; private account names, prices and personnel are excluded.", "sourceIds": [ "expansion:154" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:154" ] }, { "@id": "urn:business-engineer:model:0155", "@type": "Model", "id": 155, "stableId": "BE-M0155", "name": "Product-to-Service Boundary", "definition": "A recurring invoice can fund software, managed operation or repeated expert labor. Product economics depend on how revenue, delivery effort and recurring support change with the number and complexity of customers.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate a run-layer business or test the claim that deployment is being productized.", "evidence": "Separate subscription, implementation and managed-service revenue; measure gross profit after deployment amortization, human review, support and maintenance by comparable customer cohort.", "falsifier": "Revenue grows only with proportional expert hours, or automation merely shifts labor into hidden support and exception queues.", "decision": "Productize common operating capability while pricing irreducible expert work transparently.", "limits": "Services can be valuable and profitable. Software, not hours is a positioning intention whose economics must be demonstrated; neither pricing label nor delivery speed proves it.", "calibration": "Services can be valuable and profitable. Software, not hours is a positioning intention whose economics must be demonstrated; neither pricing label nor delivery speed proves it.", "origin": "Synthesis from WordLift run-layer and Fixpoint deployment-layer positioning, August–September 2026.", "sourceIds": [ "expansion:155" ], "usesConcept": [ "urn:business-engineer:concept:portability" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:155" ] }, { "@id": "urn:business-engineer:model:0156", "@type": "Model", "id": 156, "stableId": "BE-M0156", "name": "Reliability Budget", "definition": "End-to-end success depends on the entire path through grounding, decisions, tools, external systems, exceptions and recovery. Excellent local components can still produce unacceptable process outcomes.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate an agent workflow or compare a compelling demo with a production commitment.", "evidence": "Measure accepted end-to-end completions, correlated failures, exception categories, recovery success, worst-case consequences and performance on representative difficult cases.", "falsifier": "Local failure estimates do not predict end-to-end failures, indicating shared causes, recovery effects or an incorrect process boundary.", "decision": "Spend engineering effort where a change most improves accepted outcomes under the required risk and latency constraints.", "limits": "The product of conditional step-success probabilities is a chain rule, not an independence claim. The shortcut p^n assumes identical independent steps and no recovery; label it illustrative and do not use it as measured reliability.", "calibration": "The product of conditional step-success probabilities is a chain rule, not an independence claim. The shortcut p^n assumes identical independent steps and no recovery; label it illustrative and do not use it as measured reliability.", "origin": "Synthesis from enterprise document extraction, machine vision, RCM reliability and harness discussions, August–September 2026.", "sourceIds": [ "expansion:156" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:156" ], "instruments": [ "urn:business-engineer:instrument:drift" ] }, { "@id": "urn:business-engineer:model:0157", "@type": "Model", "id": 157, "stableId": "BE-M0157", "name": "Cost per Accepted Outcome", "aliases": [ "Cost per Accepted Outcome (The Third Bottleneck)" ], "definition": "Compare systems using total attributable cost divided by accepted outcomes over a stated period. Include inference, tools, retries, review, recovery, support and an explicit treatment of deployment cost.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D05" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Choose models or runtimes, evaluate outcome pricing, or test whether automation improves economics.", "evidence": "Define acceptance before measurement; report quality, throughput, latency and failure consequences beside cost. Use the same case mix and period for comparisons.", "falsifier": "A cheaper result fails acceptance, imposes larger downstream losses, or benefits from omitted labor and shifted costs.", "decision": "Select the configuration that meets outcome requirements at the best supported economics; expose the quality-cost tradeoff.", "limits": "Cost per outcome is undefined with no accepted outcomes. Separate marginal and fully loaded views; avoid counting the same review cost twice or valuing all outcomes identically when their stakes differ.", "calibration": "Cost per outcome is undefined with no accepted outcomes. Separate marginal and fully loaded views; avoid counting the same review cost twice or valuing all outcomes identically when their stakes differ.", "origin": "Synthesis from model routing limits, control-tower metrics and outcome-pricing discussions.", "applications": [ { "sourceId": "pack:211", "name": "Cost per Accepted Outcome", "definition": "Measure the full cost of producing an outcome that passes a defined acceptance standard, including failed attempts and necessary review.", "evidence": "Reconcile inference, tools, people, retries and operating overhead with accepted outcomes in the same period.", "falsifier": "A changed acceptance threshold or omitted rework invalidates a claimed unit-cost improvement.", "limits": "Keep quality, latency and outcome mix comparable; a token price is not an outcome cost.", "mappingKind": "equivalentMechanism" } ], "sourceIds": [ "expansion:157", "pack:211" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:counting-boundary", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:157", "urn:business-engineer:source-entry:pack:211" ], "instruments": [ "urn:business-engineer:instrument:valuation", "urn:business-engineer:instrument:verified", "urn:business-engineer:instrument:gauge-page" ], "modes": [ "urn:business-engineer:mode:deployment" ] }, { "@id": "urn:business-engineer:model:0158", "@type": "Model", "id": 158, "stableId": "BE-M0158", "name": "Evidence-to-Value Chain", "aliases": [ "The Counterfactual as Referee (Attribution Collapsed)" ], "definition": "Track five distinct claims: an intervention was delivered; behavior changed; an operational outcome improved; the improvement was attributable; economic value was realized. A dashboard observation cannot automatically jump to the last claim.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate enterprise AI pilots, AI visibility programs or benefits claimed from process deployment.", "evidence": "Specify baseline, counterfactual, exposure, measurement period and confounders; connect the operational result to an agreed economic conversion and verify realized value.", "falsifier": "A credible comparison explains the outcome without the intervention, the effect disappears under case-mix controls, or the claimed economic conversion does not occur.", "decision": "Fund the next step based on the strongest supported claim and design the cheapest credible test for the next link.", "limits": "Before-and-after movement, correlations, citations and prompt visibility are not automatically causal revenue effects. Distinguish estimated, realized and attributable savings.", "calibration": "Before-and-after movement, correlations, citations and prompt visibility are not automatically causal revenue effects. Distinguish estimated, realized and attributable savings.", "origin": "Generalized from WordLift measurement and Fixpoint Value Engineer discussions; no private client results are reproduced.", "applications": [ { "sourceId": "pack:216", "name": "Incrementality and Value Attribution", "definition": "Distinguish observed improvement from improvement caused by the intervention using a credible baseline or comparison.", "evidence": "Use randomized, staggered or matched comparisons where feasible and record confounders.", "falsifier": "Similar gains in the comparison group weaken an attributable-value claim.", "limits": "A before-and-after gauge page alone does not establish causality.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:158", "pack:216" ], "usesConcept": [ "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:baseline", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:158", "urn:business-engineer:source-entry:pack:216" ], "instruments": [ "urn:business-engineer:instrument:deploy", "urn:business-engineer:instrument:gauge-page" ], "modes": [ "urn:business-engineer:mode:deployment" ] }, { "@id": "urn:business-engineer:model:0159", "@type": "Model", "id": 159, "stableId": "BE-M0159", "name": "Incentive Compatibility Map", "definition": "An efficiency gain creates different gains and losses for the buyer, operator, seller, partner and risk owner. Adoption becomes easier when decision rights, compensation and ownership reward the behavior required for the system to work.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D07" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Explain resistance to automation, channel conflict or governance that looks strong on paper.", "evidence": "For each actor, map benefits, displaced revenue or work, new liability, required behavior, decision power and compensation.", "falsifier": "Behavior remains unchanged after the proposed incentive adjustment, suggesting capability, trust, identity or a different constraint dominates.", "decision": "Change the commercial or organizational arrangement so the actors needed for adoption can benefit from successful operation.", "limits": "Do not infer motives as facts or assume resistance is irrational. Incentive alignment does not remove capability or ethical constraints.", "calibration": "Do not infer motives as facts or assume resistance is irrational. Incentive alignment does not remove capability or ethical constraints.", "origin": "Synthesis from SI hours versus outcome economics, enterprise adoption and independent governance conversations.", "sourceIds": [ "expansion:159" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:159" ] }, { "@id": "urn:business-engineer:model:0160", "@type": "Model", "id": 160, "stableId": "BE-M0160", "name": "Autonomy Envelope", "definition": "Define the bounded conditions under which a system may act without additional human review: allowed entities, action types, scope, financial limits, evidence, reversibility, monitoring and escalation. The envelope can expand only as evidence and authority permit.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Move a bounded agent process from assisted work toward greater autonomy.", "evidence": "Exercise allowed and forbidden cases, approval triggers, rollback, monitoring coverage and escalation; verify that the authorized owner accepts the residual risk.", "falsifier": "The system cannot detect when it leaves the envelope, overrides are untraceable, or apparent success depends on constant unrecorded human rescue.", "decision": "Grant autonomy to a well-observed subset of the process and retain review at the boundaries that are consequential or uncertain.", "limits": "Model confidence alone is insufficient. Technical capability, organizational authority and acceptable risk are separate conditions; do not infer permission from an interface description.", "calibration": "Model confidence alone is insufficient. Technical capability, organizational authority and acceptable risk are separate conditions; do not infer permission from an interface description.", "origin": "Synthesis from Terms of Action, CPO boundaries and enterprise governance discussions.", "sourceIds": [ "expansion:160" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:reversibility", "urn:business-engineer:concept:autonomy-envelope" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:160" ], "instruments": [ "urn:business-engineer:instrument:charter" ] }, { "@id": "urn:business-engineer:model:0161", "@type": "Model", "id": 161, "stableId": "BE-M0161", "name": "Maintenance Burden Map", "definition": "Operating burden depends on how often requirements change, how difficult each change is and how widely it propagates. Regulation is one source alongside data drift, integrations, model changes and organizational ownership.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D06" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Compare process niches or budget the ongoing cost of maintaining a governed deployment.", "evidence": "Track update frequency, specialist effort per update, affected dependencies, revalidation time, service impact and backlog age separately.", "falsifier": "High nominal regulatory complexity generates little actual maintenance, or a low-regulation process changes more expensively through integration churn.", "decision": "Choose and price processes using observed maintenance economics; automate reusable checks and assign ownership for each change source.", "limits": "A frequency-by-complexity matrix supports comparison, not an empirically calibrated universal score. Regulatory obligations, effective dates and applicability require current primary-source verification.", "calibration": "A frequency-by-complexity matrix supports comparison, not an empirically calibrated universal score. Regulatory obligations, effective dates and applicability require current primary-source verification.", "origin": "User request to map regulatory frequency and complexity for Fixpoint, September 6, 2026; broadened to total operating maintenance.", "sourceIds": [ "expansion:161" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:drift" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:161" ] }, { "@id": "urn:business-engineer:model:0162", "@type": "Model", "id": 162, "stableId": "BE-M0162", "name": "Counter-Model Pairing", "aliases": [ "The Hostile Reading First" ], "definition": "Select a causal explanation, an economic consequence and the strongest plausible competing explanation. The purpose of multiple models is to expose different assumptions, not to create several votes for the same story.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D01", "urn:business-engineer:domain:D05" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Analyze a high-conviction strategic thesis or any case where familiar frameworks all seem to agree.", "evidence": "List shared premises, identify a discriminating observation and state what each explanation predicts differently.", "falsifier": "The models produce the same observable predictions or rely on the same evidence; the apparent comparison adds no independent information.", "decision": "Collect evidence that can choose between explanations, and reduce confidence when the current evidence cannot discriminate.", "limits": "More frameworks do not create independent confirmation. A competing model must be plausible and decision-relevant, not a straw man.", "calibration": "More frameworks do not create independent confirmation. A competing model must be plausible and decision-relevant, not a straw man.", "origin": "Methodological extension to the supplied BIA; motivated by repeated requests to check claims and avoid purely rhetorical contrarianism.", "applications": [ { "sourceId": "pack:227", "name": "Hostile Valuation Reading", "definition": "Construct the strongest credible explanation for a lower value before accepting the base case and identify evidence that distinguishes them.", "evidence": "Reconcile both cases on the same revenue boundary, capital assumptions and date.", "falsifier": "Evidence inconsistent with the hostile case should revise it rather than be dismissed.", "limits": "The hostile reading is a counter-model exercise, not a requirement to be pessimistic.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:162", "pack:227" ], "usesConcept": [ "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:162", "urn:business-engineer:source-entry:pack:227" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:strategic", "urn:business-engineer:mode:lookup" ] }, { "@id": "urn:business-engineer:model:0163", "@type": "Model", "id": 163, "stableId": "BE-M0163", "name": "Assumption and Prediction Ledger", "definition": "Separate what is observed, assumed, inferred and predicted. Record the evidence and confidence behind material claims, then return to time-bounded predictions to see which reasoning actually worked.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "framework", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Maintain a thesis across earnings prints, pilots, partner discussions or technology transitions.", "evidence": "For each material claim retain an as-of date, source, assumption, observable prediction, decision dependency, review trigger and outcome when resolved.", "falsifier": "Predictions are too vague to score, definitions shift after the fact, or confidence does not change after contrary observations.", "decision": "Revise the claim, model choice or action when discriminating evidence arrives; retain the reason for the change.", "limits": "Numerical probabilities require a coherent basis and enough comparable resolved forecasts to evaluate calibration. A narrative confidence label is not statistical calibration.", "calibration": "Numerical probabilities require a coherent basis and enough comparable resolved forecasts to evaluate calibration. A narrative confidence label is not statistical calibration.", "origin": "Extension of the supplied calibration loop, layered-map season method and editorial evidence discipline.", "sourceIds": [ "expansion:163" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:163" ], "instruments": [ "urn:business-engineer:instrument:season-map" ] }, { "@id": "urn:business-engineer:model:0164", "@type": "Model", "id": 164, "stableId": "BE-M0164", "name": "Regime-Switch Trigger", "definition": "A strategy can remain coherent while the conditions that justify it change. Define observations that move the response from monitoring to reallocation to existential response, together with observations that permit de-escalation.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Monitor competitive threats, adoption disappointments or changes in a capital-cycle thesis.", "evidence": "Specify the mechanism expected to change, the observable trigger, confirmation requirements, decision owner and response cost.", "falsifier": "Triggers fire frequently without the predicted regime change, or the response ignores evidence that the threat has receded.", "decision": "Pre-agree proportionate actions for genuinely different states and revise triggers after false alarms.", "limits": "Code Yellow, Orange and Red are optional labels, not calibrated risk categories. Avoid treating ordinary volatility as a regime switch.", "calibration": "Code Yellow, Orange and Red are optional labels, not calibrated risk categories. Avoid treating ordinary volatility as a regime switch.", "origin": "Formalizes a prior assistant-proposed Graduated Strategic Threat Response from December 13, 2025; retained as an unvalidated heuristic.", "sourceIds": [ "expansion:164" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:164" ], "instruments": [ "urn:business-engineer:instrument:drift" ] }, { "@id": "urn:business-engineer:model:0165", "@type": "Model", "id": 165, "stableId": "BE-M0165", "name": "Decision-Changing Information", "definition": "Research has value when a feasible result could change the chosen action enough to justify the cost, delay and distraction of obtaining it. Uncertainty that cannot change the decision need not be resolved first.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "decision-rule", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Choose the next diligence task, experiment or customer interview under time constraints.", "evidence": "State the current best action, the uncertain assumption, plausible results and how each result would change the action.", "falsifier": "Every plausible result leaves the decision unchanged, or collecting the information costs more than the expected improvement in the decision.", "decision": "Run the smallest credible test of the assumption with the greatest decision consequence; otherwise act or wait deliberately.", "limits": "Do not fabricate probabilities to manufacture a value-of-information number. Irreversible or high-consequence decisions may justify more diligence even when uncertainty remains.", "calibration": "Do not fabricate probabilities to manufacture a value-of-information number. Irreversible or high-consequence decisions may justify more diligence even when uncertainty remains.", "origin": "Decision-theory extension of Act vs Wait and the user’s preference for precise, actionable analysis.", "sourceIds": [ "expansion:165" ], "usesConcept": [ "urn:business-engineer:concept:reversibility" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:165" ] }, { "@id": "urn:business-engineer:model:0166", "@type": "Model", "id": 166, "stableId": "BE-M0166", "name": "Goldilocks Embedding", "definition": "A deeply embedded provider can remain durable when it continues to create value, leaves the customer enough surplus and keeps its charges within a range the customer considers justified. Dependence without continuing value increases incentives to exit or sponsor substitutes.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D01", "urn:business-engineer:domain:D09" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Evaluate platform extraction, run-layer pricing or whether strong switching costs are becoming a commercial liability.", "evidence": "Track realized customer benefit, full cost of use, price changes, renewal behavior, complaints, substitution efforts and the cost of exit.", "falsifier": "Customer surplus remains healthy but retention falls for another reason, or extraction does not create credible switching incentives in the relevant period.", "decision": "Price around continuing value and invest in improvements that make staying worthwhile; distinguish retention by value from retention by obstruction.", "limits": "The prior V/E bands above 2, between 1 and 2, and below 1 were illustrative, not validated cutoffs. Benefit estimates and price changes are often too noisy for a precise universal ratio.", "calibration": "The prior V/E bands above 2, between 1 and 2, and below 1 were illustrative, not validated cutoffs. Benefit estimates and price changes are often too noisy for a precise universal ratio.", "origin": "Refines prior assistant-proposed Goldilocks Embedding from December 13, 2025; not represented as a published empirical law.", "sourceIds": [ "expansion:166" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:residual-value" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:166" ] }, { "@id": "urn:business-engineer:model:0167", "@type": "Model", "id": 167, "stableId": "BE-M0167", "name": "Mechanism Transfer Test", "aliases": [ "The Import Test" ], "definition": "Transfer a model across domains by identifying which causal relationships must remain invariant, which variables change and which observations would make the analogy fail. Similar vocabulary or sequence is insufficient.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D01", "urn:business-engineer:domain:D09" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Compare railways with AI infrastructure, process platforms with earlier software categories, or a market pattern across countries.", "evidence": "Map actors, constraints, feedback, property rights, substitutability and time horizons in both cases; identify at least one consequential mismatch.", "falsifier": "The apparent parallel disappears after accounting for a key difference, or the analogy cannot make a prediction beyond what a generic description already gives.", "decision": "Transfer only the surviving mechanism and explicitly adapt the strategy to the new environment.", "limits": "Historical analogy is a hypothesis generator. Do not inherit dates, returns, monopoly outcomes or geopolitical succession from the reference case.", "calibration": "Historical analogy is a hypothesis generator. Do not inherit dates, returns, monopoly outcomes or geopolitical succession from the reference case.", "origin": "Extension of cross-domain synthesis prompted by the technogeopolitics framework and comparisons with AI.", "applications": [ { "sourceId": "pack:245", "name": "Same-Scale Import Test", "definition": "Transfer an external case only after matching the mechanism, scale, measured gate and date to the local decision.", "evidence": "Document the source case, contextual differences and a local test of the load-bearing assumption.", "falsifier": "A failed local gate or materially different authority structure invalidates direct transfer.", "limits": "Analogies generate hypotheses, not evidence that an outcome will repeat.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "expansion:167", "pack:245" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:167", "urn:business-engineer:source-entry:pack:245" ] }, { "@id": "urn:business-engineer:model:0168", "@type": "Model", "id": 168, "stableId": "BE-M0168", "name": "Coordination Tax", "definition": "When AI makes individual production cheaper, review, integration, decision-making and ownership can become the binding constraints. More generated output may enlarge queues without increasing completed, accepted work.", "keyQuestion": "Which decision does this mechanism change, under what conditions?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D01", "urn:business-engineer:domain:D09" ], "status": "Proposed synthesis", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Assess AI productivity across engineering, product, GTM and executive work or design an AI-enabled team.", "evidence": "Measure end-to-end cycle time, work in progress, rework, reviewer load, decision latency and accepted throughput, not just drafts or tasks generated.", "falsifier": "Output growth converts proportionally into accepted throughput without extra coordination cost, or demand rather than coordination is the binding constraint.", "decision": "Automate or simplify the handoffs and decisions that constrain completion; reduce unnecessary generation when it only adds queueing.", "limits": "Do not assume that fewer people or more Super ICs necessarily improves throughput. Accountability, expertise and coordination still need explicit coverage.", "calibration": "Do not assume that fewer people or more Super ICs necessarily improves throughput. Accountability, expertise and coordination still need explicit coverage.", "origin": "Synthesis from AI work across functions, Super IC, deployment bench and productivity discussions, August–September 2026.", "sourceIds": [ "expansion:168" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:expansion:168" ] }, { "@id": "urn:business-engineer:model:0169", "@type": "Model", "id": 169, "stableId": "BE-M0169", "name": "Repricing Mechanisms", "aliases": [ "Two Species of Drawdown" ], "definition": "Distinguish changes in expected operating cash flows, bottleneck durability, discount rates and financing capacity when explaining a drawdown.", "keyQuestion": "Which change in operating expectations, bottleneck durability, discount rates or funding capacity explains this repricing?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which change in operating expectations, bottleneck durability, discount rates or funding capacity explains this repricing?", "evidence": "Decompose forecast revisions, interest rates, leverage and liquidity around the event.", "falsifier": "Stable operations with changed discount rates challenges an operating-collapse explanation, and vice versa.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Supply and financing are useful lenses, not an exhaustive two-species taxonomy; equity losses can reflect broken economics.", "calibration": "Supply and financing are useful lenses, not an exhaustive two-species taxonomy; equity losses can reflect broken economics.", "origin": "Reconciled from expansion pack entry 138; supplied source is not independent empirical validation.", "sourceIds": [ "pack:138" ], "usesConcept": [ "urn:business-engineer:concept:constraint" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:138" ] }, { "@id": "urn:business-engineer:model:0170", "@type": "Model", "id": 170, "stableId": "BE-M0170", "name": "Political and Noncommercial Demand", "aliases": [ "The Fifth Clock (Return-Insensitive Demand)" ], "definition": "State objectives can support investment whose sponsor accepts returns different from private investors, changing demand timing and financing resilience.", "keyQuestion": "How much of this demand never had to clear a return, and does that set a floor or just fund the malinvestment?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04", "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of this demand never had to clear a return, and does that set a floor or just fund the malinvestment?", "evidence": "Identify appropriated budgets, objectives, procurement contracts, cancellation rights and fiscal constraints.", "falsifier": "Cancelled commitments or unchanged investment after state support is removed weaken the proposed demand floor.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Political demand is neither unlimited nor return-free and is not necessary or sufficient for a supercycle.", "calibration": "Political demand is neither unlimited nor return-free and is not necessary or sufficient for a supercycle.", "origin": "Reconciled from expansion pack entry 139; supplied source is not independent empirical validation.", "sourceIds": [ "pack:139" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption", "urn:business-engineer:clock:political" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:139" ], "instruments": [ "urn:business-engineer:instrument:junction" ], "modes": [ "urn:business-engineer:mode:geopolitics" ] }, { "@id": "urn:business-engineer:model:0171", "@type": "Model", "id": 171, "stableId": "BE-M0171", "name": "Geopolitical Junction Test", "aliases": [ "Sited, Standardised, Chokeable (The Junction Rule)" ], "definition": "Assess whether a technology's production sites, standards and concentrated dependencies expose it to political control.", "keyQuestion": "Is this technology sited, standardised, and chokeable, and at which junction with other technologies does it become a map?", "form": "framework", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this technology sited, standardised, and chokeable, and at which junction with other technologies does it become a map?", "evidence": "Map geography, substitutability, standard-setting authority and who can restrict access.", "falsifier": "Accessible substitutes or unenforceable restrictions weaken the claimed junction power.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Sited, standardized and chokepoint exposure are separate dimensions; no composite score is supplied.", "calibration": "Sited, standardized and chokepoint exposure are separate dimensions; no composite score is supplied.", "origin": "Reconciled from expansion pack entry 141; supplied source is not independent empirical validation.", "sourceIds": [ "pack:141" ], "usesConcept": [ "urn:business-engineer:concept:junction", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:141" ], "instruments": [ "urn:business-engineer:instrument:junction" ], "modes": [ "urn:business-engineer:mode:geopolitics" ] }, { "@id": "urn:business-engineer:model:0172", "@type": "Model", "id": 172, "stableId": "BE-M0172", "name": "Dependency Migration", "aliases": [ "The Independence Swap" ], "definition": "Adopting a technology can reduce one dependency while creating another in inputs, infrastructure, standards or permissions.", "keyQuestion": "What dependency is this independence going to invoice, and when does the bill arrive?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What dependency is this independence going to invoice, and when does the bill arrive?", "evidence": "Compare dependency and exit maps before and after adoption, including transition costs.", "falsifier": "Independent supply and exercised alternatives can refute a claimed replacement dependency.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Independence is multidimensional; replacing a dependency may still be a rational improvement.", "calibration": "Independence is multidimensional; replacing a dependency may still be a rational improvement.", "origin": "Reconciled from expansion pack entry 142; supplied source is not independent empirical validation.", "sourceIds": [ "pack:142" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:baseline" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:142" ], "instruments": [ "urn:business-engineer:instrument:junction" ], "modes": [ "urn:business-engineer:mode:geopolitics" ] }, { "@id": "urn:business-engineer:model:0173", "@type": "Model", "id": 173, "stableId": "BE-M0173", "name": "Revocable Permission Layer", "aliases": [ "The Permission Layer" ], "definition": "Access to a capability can depend on a party's continuing legal or operational permission even when its physical components are available.", "keyQuestion": "Who holds the permission this system runs on, and what does revocation look like in practice?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who holds the permission this system runs on, and what does revocation look like in practice?", "evidence": "Identify licenses, contracts, credentials, approval authority and revocation conditions.", "falsifier": "An independently operable alternative without the disputed permission weakens the dependency claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Distinguish legal authority from technical access and verify the applicable rules.", "calibration": "Distinguish legal authority from technical access and verify the applicable rules.", "origin": "Reconciled from expansion pack entry 143; supplied source is not independent empirical validation.", "sourceIds": [ "pack:143" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:permission" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:143" ], "instruments": [ "urn:business-engineer:instrument:junction" ], "modes": [ "urn:business-engineer:mode:geopolitics" ] }, { "@id": "urn:business-engineer:model:0174", "@type": "Model", "id": 174, "stableId": "BE-M0174", "name": "Control Coverage Gaps", "aliases": [ "The Fence and the Tunnel" ], "definition": "A restriction's economic effect depends on which relevant activities and jurisdictions it actually governs and how enforceably it does so.", "keyQuestion": "Where is this fence thinnest, and which layer is being tunnelled under it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where is this fence thinnest, and which layer is being tunnelled under it?", "evidence": "Compare the stated control perimeter with lawful supply, substitution and implementation evidence.", "falsifier": "Broad effective coverage and limited substitutes challenge a claim that the restriction is economically porous.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "This is a policy-effectiveness diagnostic, not an instruction to evade controls.", "calibration": "This is a policy-effectiveness diagnostic, not an instruction to evade controls.", "origin": "Reconciled from expansion pack entry 144; supplied source is not independent empirical validation.", "sourceIds": [ "pack:144" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:144" ], "instruments": [ "urn:business-engineer:instrument:junction" ] }, { "@id": "urn:business-engineer:model:0175", "@type": "Model", "id": 175, "stableId": "BE-M0175", "name": "Noncommercial Capacity Entry", "aliases": [ "State Capital Does Not Under-Build" ], "definition": "Capacity funded for strategic objectives can alter prices and investment incentives even when its sponsor uses a different return threshold.", "keyQuestion": "Is every producer in this layer still disciplined by ROIC, or has a state actor changed the objective function?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is every producer in this layer still disciplined by ROIC, or has a state actor changed the objective function?", "evidence": "Track funded capacity, delivery, utilization and price changes against a counterfactual supply path.", "falsifier": "Undelivered or uneconomic-to-operate capacity that does not change supply weakens the effect.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Announced investment is not delivered supply; demand growth and product differences matter.", "calibration": "Announced investment is not delivered supply; demand growth and product differences matter.", "origin": "Reconciled from expansion pack entry 145; supplied source is not independent empirical validation.", "sourceIds": [ "pack:145" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:145" ] }, { "@id": "urn:business-engineer:model:0176", "@type": "Model", "id": 176, "stableId": "BE-M0176", "name": "National Sector Concentration", "aliases": [ "The Toll-Booth State" ], "definition": "A sector's contribution to national income, exports or assets can create concentrated economic and political exposure.", "keyQuestion": "Which country is this layer, and what is stacked on top of that position?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which country is this layer, and what is stacked on top of that position?", "evidence": "Use consistent value-added, export, employment and fiscal measures, with supplier dependencies separated.", "falsifier": "Diversified domestic value creation and low exposure under a sector shock weaken the concentration thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Company revenue is not interchangeable with GDP or national income.", "calibration": "Company revenue is not interchangeable with GDP or national income.", "origin": "Reconciled from expansion pack entry 146; supplied source is not independent empirical validation.", "sourceIds": [ "pack:146" ], "usesConcept": [ "urn:business-engineer:concept:portability", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:146" ] }, { "@id": "urn:business-engineer:model:0177", "@type": "Model", "id": 177, "stableId": "BE-M0177", "name": "Contracted Risk Transfer", "aliases": [ "Market Risk Becomes Counterparty Risk (The Wire)" ], "definition": "A price floor or purchase commitment can replace some market-price exposure with counterparty and contractual exposure.", "keyQuestion": "When this floor contracted away its price risk, whose credit did it accept instead?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "When this floor contracted away its price risk, whose credit did it accept instead?", "evidence": "Read price, volume, indexation, termination, collateral and guarantee provisions alongside counterparty capacity.", "falsifier": "Uncovered volume or unenforceable support challenges the claimed protection.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Basis, timing, performance, demand and enforcement risks may remain.", "calibration": "Basis, timing, performance, demand and enforcement risks may remain.", "origin": "Reconciled from expansion pack entry 147; supplied source is not independent empirical validation.", "sourceIds": [ "pack:147" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:147" ] }, { "@id": "urn:business-engineer:model:0178", "@type": "Model", "id": 178, "stableId": "BE-M0178", "name": "Payment Certainty and Capacity Adaptability", "aliases": [ "Shape Cannot Be Contracted" ], "definition": "Predictable contracted payments and the ability to adapt an asset to changing demand are separate sources of resilience.", "keyQuestion": "What does this contract fix, and what does it leave to move?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What does this contract fix, and what does it leave to move?", "evidence": "Stress payment obligations and asset reuse under technology and customer changes.", "falsifier": "Secure payment with stranded capacity, or flexible capacity without funding, breaks the inference that one ensures the other.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Do not treat payment certainty as proof of asset usefulness or solvency.", "calibration": "Do not treat payment certainty as proof of asset usefulness or solvency.", "origin": "Reconciled from expansion pack entry 148; supplied source is not independent empirical validation.", "sourceIds": [ "pack:148" ], "usesConcept": [ "urn:business-engineer:concept:obligation" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:148" ] }, { "@id": "urn:business-engineer:model:0179", "@type": "Model", "id": 179, "stableId": "BE-M0179", "name": "Inflation and Financing Feedback", "aliases": [ "The Transmission Belt" ], "definition": "Input or energy cost shocks can affect prices, interest rates, financing capacity and subsequent investment through several contingent channels.", "keyQuestion": "Through which shared input does this buildout reach a price a household pays, and how does that price come back as a cost of capital?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Through which shared input does this buildout reach a price a household pays, and how does that price come back as a cost of capital?", "evidence": "Trace pass-through, policy response, real rates and funding conditions with dated evidence.", "falsifier": "Absorbed costs or offsetting monetary and demand effects weaken the proposed transmission.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The sign and strength depend on contracts, policy and the broader economy.", "calibration": "The sign and strength depend on contracts, policy and the broader economy.", "origin": "Reconciled from expansion pack entry 149; supplied source is not independent empirical validation.", "sourceIds": [ "pack:149" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:149" ] }, { "@id": "urn:business-engineer:model:0180", "@type": "Model", "id": 180, "stableId": "BE-M0180", "name": "Merchant Market Compression", "aliases": [ "Demand Subtraction Wearing a Supply Costume" ], "definition": "Vertical integration can reduce purchases in an open merchant market while the underlying service or workload continues growing internally.", "keyQuestion": "Is this new capacity adding to the market or removing a customer from it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this new capacity adding to the market or removing a customer from it?", "evidence": "Reconcile third-party sales, internal capacity and total workload with consistent boundaries.", "falsifier": "Stable merchant share alongside integration weakens the claimed compression.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Captive and merchant capacity are not automatically equivalent in cost or performance.", "calibration": "Captive and merchant capacity are not automatically equivalent in cost or performance.", "origin": "Reconciled from expansion pack entry 151; supplied source is not independent empirical validation.", "sourceIds": [ "pack:151" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:151" ] }, { "@id": "urn:business-engineer:model:0181", "@type": "Model", "id": 181, "stableId": "BE-M0181", "name": "Production Scale and Interdiction Exposure", "aliases": [ "The Land–Sea Oscillation and the Blockade's Medium" ], "definition": "The geography and substitutability of production can change how disruption affects economic and strategic power.", "keyQuestion": "Through which medium would a blockade of this system run, and does the current junction favour mass or exquisiteness?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D04" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Through which medium would a blockade of this system run, and does the current junction favour mass or exquisiteness?", "evidence": "Compare historically documented production capacity, replacement time and supply continuity.", "falsifier": "Rapid substitution or dispersed production weakens a concentration-based exposure claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Historical strategic analysis requires case-specific evidence; no operational targeting guidance is implied.", "calibration": "Historical strategic analysis requires case-specific evidence; no operational targeting guidance is implied.", "origin": "Reconciled from expansion pack entry 152; supplied source is not independent empirical validation.", "sourceIds": [ "pack:152" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:152" ] }, { "@id": "urn:business-engineer:model:0182", "@type": "Model", "id": 182, "stableId": "BE-M0182", "name": "Economic Seat Taxonomy", "aliases": [ "Name the Seat First" ], "definition": "Classify an actor's position in a flow of spending, production, financing, access and incidence before applying a performance test.", "keyQuestion": "Which of the ten seats is this company in, and am I running that seat's test or someone else's?", "form": "taxonomy", "domains": [ "urn:business-engineer:domain:D05", "urn:business-engineer:domain:D02" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of the ten seats is this company in, and am I running that seat's test or someone else's?", "evidence": "Name the payer, contractual role, unit, layer and horizon for each exposure.", "falsifier": "Different conclusions for different exposures within one company show that a single firm-wide seat is insufficient.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The ten seats overlap; a renter is a comparator, not automatically a causal control group.", "calibration": "The ten seats overlap; a renter is a comparator, not automatically a causal control group.", "origin": "Reconciled from expansion pack entry 154; supplied source is not independent empirical validation.", "sourceIds": [ "pack:154" ], "usesConcept": [ "urn:business-engineer:concept:seat", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:154" ], "instruments": [ "urn:business-engineer:instrument:capital-print", "urn:business-engineer:instrument:incidence" ], "modes": [ "urn:business-engineer:mode:print" ] }, { "@id": "urn:business-engineer:model:0183", "@type": "Model", "id": 183, "stableId": "BE-M0183", "name": "Asset-Light Exposure", "aliases": [ "The Value-Capture Pole (The Anti-Capex Node)" ], "definition": "Low owned capital can coexist with substantial lease, minimum-purchase, supplier, access and counterparty obligations.", "keyQuestion": "Does this company pay for the build or get paid by it, and if the latter, where does its risk live?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this company pay for the build or get paid by it, and if the latter, where does its risk live?", "evidence": "Reconcile owned assets with leases, contracted capacity and economically necessary purchases.", "falsifier": "Flexible cancellable access with adequate alternatives weakens a claimed hidden capital burden.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Asset-light is a balance-sheet and operating description, not a synonym for low risk.", "calibration": "Asset-light is a balance-sheet and operating description, not a synonym for low risk.", "origin": "Reconciled from expansion pack entry 155; supplied source is not independent empirical validation.", "sourceIds": [ "pack:155" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:155" ] }, { "@id": "urn:business-engineer:model:0184", "@type": "Model", "id": 184, "stableId": "BE-M0184", "name": "Local Proof and System Scale", "aliases": [ "Proof of Concept, Not Reconciliation" ], "definition": "A viable product or profitable node does not establish that the surrounding industry's investment can earn adequate returns.", "keyQuestion": "Is this return real, and is it remotely scaled to the capital it is supposed to justify?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this return real, and is it remotely scaled to the capital it is supposed to justify?", "evidence": "Compare local unit economics with aggregate capital, final demand and duplication across layers.", "falsifier": "A consistent system-level cash-flow reconciliation can support broader viability beyond the local proof.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Do not sum intermediate supplier revenue as independent final demand.", "calibration": "Do not sum intermediate supplier revenue as independent final demand.", "origin": "Reconciled from expansion pack entry 156; supplied source is not independent empirical validation.", "sourceIds": [ "pack:156" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:156" ] }, { "@id": "urn:business-engineer:model:0185", "@type": "Model", "id": 185, "stableId": "BE-M0185", "name": "Operating Performance and Valuation Duration", "aliases": [ "Price Is the Whole Position" ], "definition": "An operating business can improve while its valuation falls because expectations, discount rates or the timing of cash flows change.", "keyQuestion": "If this company has no asset to reprice, what is the tape actually repricing?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "If this company has no asset to reprice, what is the tape actually repricing?", "evidence": "Reconcile operating revisions, priced growth, discount rates and cash-flow duration.", "falsifier": "Deteriorating expected operations challenges a pure-duration explanation.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A price decline is evidence to explain, not proof of unchanged economics.", "calibration": "A price decline is evidence to explain, not proof of unchanged economics.", "origin": "Reconciled from expansion pack entry 157; supplied source is not independent empirical validation.", "sourceIds": [ "pack:157" ], "usesConcept": [ "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:157" ] }, { "@id": "urn:business-engineer:model:0186", "@type": "Model", "id": 186, "stableId": "BE-M0186", "name": "Circular Commercial and Financial Exposure", "aliases": [ "The Related-Party Triple (The Circle)" ], "definition": "A supplier, investor and customer relationship can create correlated funding and revenue exposure when money moves through linked counterparties.", "keyQuestion": "How many effects does this one relationship produce in the accounts, and which of them are the same dollar?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How many effects does this one relationship produce in the accounts, and which of them are the same dollar?", "evidence": "Trace counterparties, funding sources, commercial contracts, timing and related-party disclosures.", "falsifier": "Independent customer budgets and sustained purchases without supplier financing weaken a circular-dependence thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Such revenue is not automatically fictitious; accounting recognition and demand independence are different questions.", "calibration": "Such revenue is not automatically fictitious; accounting recognition and demand independence are different questions.", "origin": "Reconciled from expansion pack entry 160; supplied source is not independent empirical validation.", "sourceIds": [ "pack:160" ], "usesConcept": [ "urn:business-engineer:concept:clock", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:circle", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:160" ], "instruments": [ "urn:business-engineer:instrument:valuation" ] }, { "@id": "urn:business-engineer:model:0187", "@type": "Model", "id": 187, "stableId": "BE-M0187", "name": "Leveraged Equity Funding", "aliases": [ "The Levered Backer" ], "definition": "Borrowing to fund equity exposure combines a relatively fixed obligation with a volatile residual claim.", "keyQuestion": "Is the first-loss equity beneath this structure real equity, or borrowed against the asset it bought?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is the first-loss equity beneath this structure real equity, or borrowed against the asset it bought?", "evidence": "Stress debt service, collateral, refinancing and equity value under correlated shocks.", "falsifier": "Unlevered exposure or matching long-term committed resources weakens a forced-sale thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Funding maturity, recourse and liquidity determine the risk, not equity ownership alone.", "calibration": "Funding maturity, recourse and liquidity determine the risk, not equity ownership alone.", "origin": "Reconciled from expansion pack entry 161; supplied source is not independent empirical validation.", "sourceIds": [ "pack:161" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:161" ] }, { "@id": "urn:business-engineer:model:0188", "@type": "Model", "id": 188, "stableId": "BE-M0188", "name": "Valuation Update Lag", "aliases": [ "The Frozen Mark" ], "definition": "Reported marks for illiquid holdings can adjust later or less frequently than observable market conditions.", "keyQuestion": "Which mark in this book has not moved, and what would force it to?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which mark in this book has not moved, and what would force it to?", "evidence": "Compare valuation dates, methodologies, transactions and subsequent events for comparable exposures.", "falsifier": "Independent contemporaneous transactions supporting a mark weaken a lag claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "An unchanged mark alone is not evidence of manipulation or an incorrect valuation.", "calibration": "An unchanged mark alone is not evidence of manipulation or an incorrect valuation.", "origin": "Reconciled from expansion pack entry 162; supplied source is not independent empirical validation.", "sourceIds": [ "pack:162" ], "usesConcept": [ "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:162" ] }, { "@id": "urn:business-engineer:model:0189", "@type": "Model", "id": 189, "stableId": "BE-M0189", "name": "Customer-Funded Working Capital", "aliases": [ "Backlog as Payable (The Customer Is the Lender)" ], "definition": "Customer cash collected before delivery can fund operations while creating delivery, refund and concentration obligations.", "keyQuestion": "How do advance receipts, delivery obligations and customer concentration affect cash generation and the remaining funding risk?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How do advance receipts, delivery obligations and customer concentration affect cash generation and the remaining funding risk?", "evidence": "Reconcile billings, cash receipts, receivables, contract assets, contract liabilities and delivery schedules.", "falsifier": "Short-lived advances offset by refunds or supplier payments weaken a durable-float thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Backlog is not automatically a receivable or liability; classify rights and performance obligations separately.", "calibration": "Backlog is not automatically a receivable or liability; classify rights and performance obligations separately.", "origin": "Reconciled from expansion pack entry 163; supplied source is not independent empirical validation.", "sourceIds": [ "pack:163" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:obligation" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:163" ] }, { "@id": "urn:business-engineer:model:0190", "@type": "Model", "id": 190, "stableId": "BE-M0190", "name": "Integrator Working Capital Exposure", "aliases": [ "Assembly Is Not Capture (The Integrator Floats the Timing Gap)" ], "definition": "An integrator can finance the gap between supplier payment and customer collection even when it owns little long-lived infrastructure.", "keyQuestion": "Who is carrying the working capital of this build, and is it being extended as trade credit to counterparties the acid test never scores?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who is carrying the working capital of this build, and is it being extended as trade credit to counterparties the acid test never scores?", "evidence": "Measure inventory, payment terms, receivable aging, credit insurance and stressed cash conversion.", "falsifier": "Matched payment timing or reliable nonrecourse transfer weakens the financing-gap thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The original financing gauges need a trade-credit supplement to capture this exposure.", "calibration": "The original financing gauges need a trade-credit supplement to capture this exposure.", "origin": "Reconciled from expansion pack entry 164; supplied source is not independent empirical validation.", "sourceIds": [ "pack:164" ], "usesConcept": [ "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:164" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0191", "@type": "Model", "id": 191, "stableId": "BE-M0191", "name": "Scarcity Rent and Structural Rent", "aliases": [ "Tightness Rent vs Monopoly Rent (The Arms Dealer)" ], "definition": "Separate returns caused by a temporary shortage from returns sustained by hard-to-replicate control, capabilities or relationships.", "keyQuestion": "Is this margin a property of the constraint or of the position, and who else can supply once the constraint eases?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this margin a property of the constraint or of the position, and who else can supply once the constraint eases?", "evidence": "Track capacity additions, substitutes, price premiums, retention and bargaining power after scarcity eases.", "falsifier": "Persistent premiums with verified customer value challenge a purely temporary-rent diagnosis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The two mechanisms can coexist; high margins alone identify neither.", "calibration": "The two mechanisms can coexist; high margins alone identify neither.", "origin": "Reconciled from expansion pack entry 165; supplied source is not independent empirical validation.", "sourceIds": [ "pack:165" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:165" ] }, { "@id": "urn:business-engineer:model:0192", "@type": "Model", "id": 192, "stableId": "BE-M0192", "name": "Customer Equity Incentives", "aliases": [ "The Vertical Wrapper (Paying to Enter the Build)" ], "definition": "Equity or warrant incentives offered to customers can alter effective pricing, acquisition economics and the distribution of business risk.", "keyQuestion": "How much of this 'core' revenue is an add-back of equity handed to the customer?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of this 'core' revenue is an add-back of equity handed to the customer?", "evidence": "Value contractual incentives consistently and compare retention and purchases after subsidies expire.", "falsifier": "Unsubsidized repeat demand weakens a thesis that the incentive alone supports the relationship.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Noncash incentives still have an economic cost; avoid double counting dilution and expense adjustments.", "calibration": "Noncash incentives still have an economic cost; avoid double counting dilution and expense adjustments.", "origin": "Reconciled from expansion pack entry 167; supplied source is not independent empirical validation.", "sourceIds": [ "pack:167" ], "usesConcept": [ "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:167" ] }, { "@id": "urn:business-engineer:model:0193", "@type": "Model", "id": 193, "stableId": "BE-M0193", "name": "Group Value-Source Migration", "aliases": [ "The Sibling Engine (The Gravity Shift)" ], "definition": "A diversified group's source of value can shift between businesses even while aggregate results conceal the transition.", "keyQuestion": "Which entity in this group is now the engine, and which is being carried by a mark on it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which entity in this group is now the engine, and which is being carried by a mark on it?", "evidence": "Bridge segment cash flows, capital requirements and risk to group valuation over time.", "falsifier": "Stable segment contributions weaken a proposed migration of the value center.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Intersegment transactions and shared costs need reconciliation.", "calibration": "Intersegment transactions and shared costs need reconciliation.", "origin": "Reconciled from expansion pack entry 168; supplied source is not independent empirical validation.", "sourceIds": [ "pack:168" ], "usesConcept": [ "urn:business-engineer:concept:portability" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:168" ] }, { "@id": "urn:business-engineer:model:0194", "@type": "Model", "id": 194, "stableId": "BE-M0194", "name": "Credit-Supported Asset Financing", "aliases": [ "The Rating Is the Collateral" ], "definition": "Long-lived asset financing often depends on the credit quality and tenor of customers, sponsors or other contractual supporters.", "keyQuestion": "Which rating is really being pledged here, through which seam would it leak, and who is assumed to take the paper out?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which rating is really being pledged here, through which seam would it leak, and who is assumed to take the paper out?", "evidence": "Match asset life and five listed tenor categories with funding maturities, support and refinancing conditions.", "falsifier": "Weak or short-lived credit support can break financing even when the asset has demand.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The source says four tenors but lists five; support reduces some risks without eliminating them.", "calibration": "The source says four tenors but lists five; support reduces some risks without eliminating them.", "origin": "Reconciled from expansion pack entry 170; supplied source is not independent empirical validation.", "sourceIds": [ "pack:170" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "analyzedThroughClock": [ "urn:business-engineer:clock:physical", "urn:business-engineer:clock:financial", "urn:business-engineer:clock:efficiency", "urn:business-engineer:clock:adoption" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:170" ], "instruments": [ "urn:business-engineer:instrument:financing" ] }, { "@id": "urn:business-engineer:model:0195", "@type": "Model", "id": 195, "stableId": "BE-M0195", "name": "Merchant and Captive Measurement Boundary", "aliases": [ "The Rack Ate a Layer (The Invisible Channels)" ], "definition": "Separate open-market transactions from internal production when estimating market size, shares and investment returns.", "keyQuestion": "Which channels of this build are invisible to the public numbers, and how much does that bias the read?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which channels of this build are invisible to the public numbers, and how much does that bias the read?", "evidence": "Reconcile merchant revenue, captive capacity, internal transfers and final-customer spending.", "falsifier": "A stable reconciled boundary can overturn a growth claim driven only by reclassification.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Use different totals for different questions and never silently add them.", "calibration": "Use different totals for different questions and never silently add them.", "origin": "Reconciled from expansion pack entry 172; supplied source is not independent empirical validation.", "sourceIds": [ "pack:172" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:172" ] }, { "@id": "urn:business-engineer:model:0196", "@type": "Model", "id": 196, "stableId": "BE-M0196", "name": "AI Cost Incidence in Software", "aliases": [ "Software Acquires a Cost of Goods" ], "definition": "AI can add workload-sensitive production costs to software and redistribute margin pressure through the product and supplier stack.", "keyQuestion": "Where in this software P&L is the inference bill landing, and what lever pulls the margin back?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where in this software P&L is the inference bill landing, and what lever pulls the margin back?", "evidence": "Measure inference, tools, support, retries and review cost by user and accepted outcome.", "falsifier": "Low or declining incremental cost relative to realized value weakens a margin-compression thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Software already had nonzero costs; AI cost structure varies by architecture and usage.", "calibration": "Software already had nonzero costs; AI cost structure varies by architecture and usage.", "origin": "Reconciled from expansion pack entry 174; supplied source is not independent empirical validation.", "sourceIds": [ "pack:174" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:174" ] }, { "@id": "urn:business-engineer:model:0197", "@type": "Model", "id": 197, "stableId": "BE-M0197", "name": "Discovery Channel Erosion", "aliases": [ "The Discovery Tax (The Curse Is in the Funnel)" ], "definition": "A change in how users discover answers can reduce or redirect referrals and monetization for businesses dependent on the prior channel.", "keyQuestion": "Is this revenue being generated by the funnel or by squeezing a base the funnel stopped refilling?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this revenue being generated by the funnel or by squeezing a base the funnel stopped refilling?", "evidence": "Track task-level impressions, referrals, conversion, direct demand and alternate acquisition routes.", "falsifier": "Stable profitable conversion despite fewer visits weakens a revenue-loss inference.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Traffic, qualified demand and revenue are distinct; effects differ by task and segment.", "calibration": "Traffic, qualified demand and revenue are distinct; effects differ by task and segment.", "origin": "Reconciled from expansion pack entry 175; supplied source is not independent empirical validation.", "sourceIds": [ "pack:175" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:175" ] }, { "@id": "urn:business-engineer:model:0198", "@type": "Model", "id": 198, "stableId": "BE-M0198", "name": "Information Substitution and Transaction Completion", "aliases": [ "Content Is Summarizable, Settlement Must Clear" ], "definition": "An agent may substitute for an informational step without being able or authorized to complete the associated transaction.", "keyQuestion": "Can an agent satisfy this demand with a summary, or does something still have to clear?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Can an agent satisfy this demand with a summary, or does something still have to clear?", "evidence": "Test discovery, interpretation, permission, payment and exception handling separately.", "falsifier": "Successful authorized completion can refute a claim that the business controls an indispensable final step.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A content response is not evidence of execution capability.", "calibration": "A content response is not evidence of execution capability.", "origin": "Reconciled from expansion pack entry 176; supplied source is not independent empirical validation.", "sourceIds": [ "pack:176" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:176" ] }, { "@id": "urn:business-engineer:model:0199", "@type": "Model", "id": 199, "stableId": "BE-M0199", "name": "Machine-Access Monetization", "aliases": [ "The Toll Authority (The Property Line Repriced)" ], "definition": "A business may charge for reliable machine access to information, actions or outcomes when those services create measurable value.", "keyQuestion": "Has this toll authority secured the position, and is it collecting yet or still carrying the traffic free?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Has this toll authority secured the position, and is it collecting yet or still carrying the traffic free?", "evidence": "Test paying demand, access rights, substitution, service quality and delivery cost.", "falsifier": "Cheap equivalent lawful access or weak willingness to pay undermines the toll thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Technical access control alone does not create a durable rent.", "calibration": "Technical access control alone does not create a durable rent.", "origin": "Reconciled from expansion pack entry 178; supplied source is not independent empirical validation.", "sourceIds": [ "pack:178" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:178" ] }, { "@id": "urn:business-engineer:model:0200", "@type": "Model", "id": 200, "stableId": "BE-M0200", "name": "Interface-to-Substrate Transition", "aliases": [ "The Interface Concession" ], "definition": "A product can lose control of the user interface yet retain value as the system that performs transactions, enforces rules or stores authoritative state.", "keyQuestion": "Has this incumbent conceded the interface, and what is the substrate business worth once it has?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Has this incumbent conceded the interface, and what is the substrate business worth once it has?", "evidence": "Separate interface usage from backend transaction volume, switching cost and retained economics.", "falsifier": "Replaceable backend services with falling retained margin weaken the substrate defense.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Losing the interface may still weaken distribution and bargaining power.", "calibration": "Losing the interface may still weaken distribution and bargaining power.", "origin": "Reconciled from expansion pack entry 179; supplied source is not independent empirical validation.", "sourceIds": [ "pack:179" ], "usesConcept": [ "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:179" ] }, { "@id": "urn:business-engineer:model:0201", "@type": "Model", "id": 201, "stableId": "BE-M0201", "name": "Segment-Level Substitution", "aliases": [ "Substitution Shows Up in the Segments Before the Total" ], "definition": "Technology substitution depends on the task, customer and workflow segment, so aggregate company labels can conceal opposing effects.", "keyQuestion": "Which segment inside this total has gone negative, and which agent behaviour explains it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which segment inside this total has gone negative, and which agent behaviour explains it?", "evidence": "Compare adoption, quality, switching and economics by segment.", "falsifier": "Uniform effects across well-defined segments weaken the need for a segmented explanation.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Define segments before observing the outcome to reduce convenient reclassification.", "calibration": "Define segments before observing the outcome to reduce convenient reclassification.", "origin": "Reconciled from expansion pack entry 180; supplied source is not independent empirical validation.", "sourceIds": [ "pack:180" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:180" ] }, { "@id": "urn:business-engineer:model:0202", "@type": "Model", "id": 202, "stableId": "BE-M0202", "name": "Metric Definition Drift", "aliases": [ "The Definition Moved With the Number" ], "definition": "A reported metric can change because its counting rule, population or period changed rather than because the underlying business improved.", "keyQuestion": "What changed in the definition of this number, and in which quarter did the change arrive?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D01" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What changed in the definition of this number, and in which quarter did the change arrive?", "evidence": "Maintain a definition ledger and recompute comparable series where data permits.", "falsifier": "Stable definitions and reconciled denominators support a real change in performance.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A changed definition can be legitimate; disclose its effect without assuming intent.", "calibration": "A changed definition can be legitimate; disclose its effect without assuming intent.", "origin": "Reconciled from expansion pack entry 181; supplied source is not independent empirical validation.", "sourceIds": [ "pack:181" ], "usesConcept": [ "urn:business-engineer:concept:counting-boundary", "urn:business-engineer:concept:drift" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:181" ] }, { "@id": "urn:business-engineer:model:0203", "@type": "Model", "id": 203, "stableId": "BE-M0203", "name": "Earnings per Share Attribution", "aliases": [ "Growth Bought, Not Grown" ], "definition": "Changes in earnings per share can arise from operations, financing, taxes, marks and share-count changes with different durability.", "keyQuestion": "How much of this earnings growth is operating, how much is a mark, and how much is a smaller share count bought with debt?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How much of this earnings growth is operating, how much is a mark, and how much is a smaller share count bought with debt?", "evidence": "Bridge net income and weighted shares to EPS, separating operating and non-operating components.", "falsifier": "Stable share count and clean operating improvement weaken a financial-engineering explanation.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Buybacks are not automatically value creating; price paid, financing and alternatives matter.", "calibration": "Buybacks are not automatically value creating; price paid, financing and alternatives matter.", "origin": "Reconciled from expansion pack entry 182; supplied source is not independent empirical validation.", "sourceIds": [ "pack:182" ], "usesConcept": [ "urn:business-engineer:concept:residual-value", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:182" ] }, { "@id": "urn:business-engineer:model:0204", "@type": "Model", "id": 204, "stableId": "BE-M0204", "name": "Free-Tier Unit Economics", "aliases": [ "Get Big Fast, Monetize Later vs Paid From Day One", "The Free User Is a Cost" ], "definition": "A free user creates costs and potential future value; evaluate acquisition, conversion, learning and network benefits against actual delivery expense.", "keyQuestion": "Is this company's free tier an asset it monetizes elsewhere or a bill it has not yet found a payer for?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this company's free tier an asset it monetizes elsewhere or a bill it has not yet found a payer for?", "evidence": "Measure cohort contribution, conversion, retention, compute and support cost over a stated horizon.", "falsifier": "Profitable conversion or network effects can justify a free tier despite positive marginal cost.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Paid-from-day-one is an option, not a universal requirement; web products also had costs.", "calibration": "Paid-from-day-one is an option, not a universal requirement; web products also had costs.", "origin": "Reconciled from expansion pack entry 186; supplied source is not independent empirical validation.", "applications": [ { "sourceId": "pack:259", "name": "Free Growth and Paid Entry", "definition": "Choose free, paid or mixed entry by comparing customer acquisition and learning benefits with actual servicing cost and conversion.", "evidence": "Model cohort contribution, capacity use, willingness to pay and alternative acquisition paths.", "falsifier": "Profitable free cohorts undermine a claim that every AI wedge must charge immediately.", "limits": "Neither web distribution nor AI delivery has a universal marginal-cost law.", "mappingKind": "equivalentMechanism" } ], "sourceIds": [ "pack:186", "pack:259" ], "usesConcept": [ "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:186", "urn:business-engineer:source-entry:pack:259" ] }, { "@id": "urn:business-engineer:model:0205", "@type": "Model", "id": 205, "stableId": "BE-M0205", "name": "Revenue Architecture Comparison", "aliases": [ "The Three-Column Ledger" ], "definition": "Compare revenue architectures through consistent payer, unit, cost, distribution, retention, control and capital assumptions.", "keyQuestion": "In which column does this business sit on each row, and which two rows changed?", "form": "framework", "domains": [ "urn:business-engineer:domain:D02" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "In which column does this business sit on each row, and which two rows changed?", "evidence": "Populate a common comparison table using the same period and definitions for each architecture.", "falsifier": "Unreconciled units or omitted costs make an apparent advantage non-comparable.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The nine rows are unit of sale, cost of goods, gross margin, price, customer shape, free user, moat, balance sheet and metric; populate observations rather than assuming era-wide economics.", "calibration": "The nine rows are unit of sale, cost of goods, gross margin, price, customer shape, free user, moat, balance sheet and metric; populate observations rather than assuming era-wide economics.", "origin": "Reconciled from expansion pack entry 188; supplied source is not independent empirical validation.", "sourceIds": [ "pack:188" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:188" ] }, { "@id": "urn:business-engineer:model:0206", "@type": "Model", "id": 206, "stableId": "BE-M0206", "name": "Information Inputs and Value Appropriation", "aliases": [ "The Data Oil and the Second Barrel" ], "definition": "Value from widely available informational inputs can accrue to the intermediary that organizes or distributes them; privately generated decision records may create a different opportunity for retained value.", "keyQuestion": "Who refined this firm's first barrel, and is the second barrel priced and owned before the first runs out?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who refined this firm's first barrel, and is the second barrel priced and owned before the first runs out?", "evidence": "Trace input rights, contributor compensation, traffic or other exchange benefits, intermediary economics and the ownership and substitutability of operating records.", "falsifier": "Contributors retaining bargaining power or intermediaries unable to capture incremental value weaken the appropriation thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The web-history and recursive-data claims are case hypotheses requiring evidence. Decision records are not automatically unique, owned, lawful to reuse or economically valuable.", "calibration": "The web-history and recursive-data claims are case hypotheses requiring evidence. Decision records are not automatically unique, owned, lawful to reuse or economically valuable.", "origin": "Reconciled from expansion pack entry 189; supplied source is not independent empirical validation.", "sourceIds": [ "pack:189" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:189" ] }, { "@id": "urn:business-engineer:model:0207", "@type": "Model", "id": 207, "stableId": "BE-M0207", "name": "Multi-Axis Routing", "aliases": [ "The Harness Is a Router" ], "definition": "Routing spans model choice, execution stage, hardware, cost, jurisdiction and policy. Choose among feasible allocations using quality, latency, total cost, authority and risk criteria.", "keyQuestion": "Where in this stack is the routing decision made, on how many axes, and who owns the rules that make it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where in this stack is the routing decision made, on how many axes, and who owns the rules that make it?", "evidence": "Map the six source dimensions separately from selection criteria, then compare routed outcomes against a fixed-allocation baseline.", "falsifier": "A simpler allocation with equivalent accepted quality, compliance and lower overhead weakens the routing advantage.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The six dimensions are a useful design inventory, not a universal optimization formula; value need not concentrate in the router.", "calibration": "The six dimensions are a useful design inventory, not a universal optimization formula; value need not concentrate in the router.", "origin": "Reconciled from expansion pack entry 190; supplied source is not independent empirical validation.", "sourceIds": [ "pack:190" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:baseline" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:190" ] }, { "@id": "urn:business-engineer:model:0208", "@type": "Model", "id": 208, "stableId": "BE-M0208", "name": "Routing Across Scales", "aliases": [ "Routing Is Fractal" ], "definition": "Resource-allocation patterns can recur at task, workflow, team and firm levels, but the authority and feedback at each level differ.", "keyQuestion": "At which altitude is this router operating, and what does the same pattern look like one rung up and one rung down?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "At which altitude is this router operating, and what does the same pattern look like one rung up and one rung down?", "evidence": "Match the allocation mechanism, decision rights and feedback speed before transferring a routing analogy.", "falsifier": "A mismatch in authority or observability invalidates the cross-scale transfer.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "This is a comparative lens, not proof that all scales follow one fractal law.", "calibration": "This is a comparative lens, not proof that all scales follow one fractal law.", "origin": "Reconciled from expansion pack entry 191; supplied source is not independent empirical validation.", "sourceIds": [ "pack:191" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:191" ] }, { "@id": "urn:business-engineer:model:0209", "@type": "Model", "id": 209, "stableId": "BE-M0209", "name": "Model, Harness and Context Fit", "aliases": [ "The Co-Adaptation Principle" ], "definition": "System performance depends on interactions among the model, orchestration, context, tools and evaluation design.", "keyQuestion": "Am I improving the model, or the fit between model, harness, and context, and which one is cheaper to move?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Am I improving the model, or the fit between model, harness, and context, and which one is cheaper to move?", "evidence": "Test component changes and combinations on representative tasks with equal resource accounting.", "falsifier": "No interaction effect or a simpler configuration matching results weakens a co-adaptation thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A successful benchmark configuration may not generalize to new tasks or releases.", "calibration": "A successful benchmark configuration may not generalize to new tasks or releases.", "origin": "Reconciled from expansion pack entry 193; supplied source is not independent empirical validation.", "sourceIds": [ "pack:193" ], "usesConcept": [ "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:193" ] }, { "@id": "urn:business-engineer:model:0210", "@type": "Model", "id": 210, "stableId": "BE-M0210", "name": "Cross-Depth Artifact Reuse", "aliases": [ "Depth Collapse" ], "definition": "A structured artifact created for retrieval can also support training or model adaptation if its rights, representation and quality permit reuse across those depths.", "keyQuestion": "Which artifact built for retrieval is also this firm's training substrate, and does it hold clear title to it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which artifact built for retrieval is also this firm's training substrate, and does it hold clear title to it?", "evidence": "Test a grounding graph or retrieval corpus as adaptation data, measuring transformation effort, held-out performance, provenance and permitted uses.", "falsifier": "Large reconstruction cost, rights restrictions or no improvement on fresh tasks weakens the cross-depth reuse claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Retrieval suitability does not guarantee training suitability, model ownership or a ready path to a co-designed model.", "calibration": "Retrieval suitability does not guarantee training suitability, model ownership or a ready path to a co-designed model.", "origin": "Reconciled from expansion pack entry 195; supplied source is not independent empirical validation.", "sourceIds": [ "pack:195" ], "usesConcept": [ "urn:business-engineer:concept:suite", "urn:business-engineer:concept:ownership" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:195" ] }, { "@id": "urn:business-engineer:model:0211", "@type": "Model", "id": 211, "stableId": "BE-M0211", "name": "Selective Openness", "aliases": [ "Restriction vs Diffusion (Openness as Demand Policy)", "The Palantir Paradox" ], "definition": "Opening an interface or complement can increase adoption and demand for a retained junction while leaving selected rules, assets or distribution under the firm's control.", "keyQuestion": "Which layer does this actor want open, which does it hold, and what does the roster of absences say?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which layer does this actor want open, which does it hold, and what does the roster of absences say?", "evidence": "Map licenses, interoperability and export rights, then measure induced adoption, demand for the retained component, monetization and switching costs.", "falsifier": "Open complements that enable substitutes without increasing profitable demand weaken the demand-policy thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Open interfaces, open source and open weights grant different rights; openness need not increase rent capture.", "calibration": "Open interfaces, open source and open weights grant different rights; openness need not increase rent capture.", "origin": "Reconciled from expansion pack entry 196; supplied source is not independent empirical validation.", "applications": [ { "sourceId": "pack:197", "name": "Openness as a Competitive Boundary", "definition": "Use a company case to ask which interfaces are opened and which economically important functions remain controlled.", "evidence": "Verify current product terms, interoperability and switching evidence for the named case.", "falsifier": "Usable alternatives without dependence challenge the proposed boundary.", "limits": "The source's Palantir example is a historical illustration, not a verified current company fact.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "pack:196", "pack:197" ], "usesConcept": [ "urn:business-engineer:concept:junction", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:rent" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:196", "urn:business-engineer:source-entry:pack:197" ] }, { "@id": "urn:business-engineer:model:0212", "@type": "Model", "id": 212, "stableId": "BE-M0212", "name": "Capability Absorption Risk", "aliases": [ "The Absorption Line (The Sixth Risk)" ], "definition": "A feature can lose independent value when an upstream platform incorporates a sufficiently good substitute into an existing distribution channel.", "keyQuestion": "Which parts of this product compensate for a temporary gap, and which would the firm still need after the next release?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D02" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which parts of this product compensate for a temporary gap, and which would the firm still need after the next release?", "evidence": "Compare roadmap evidence, task quality, bundling, customer switching and the product's retained assets.", "falsifier": "Persistent willingness to pay for differentiated workflow value weakens the absorption thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A release announcement does not prove substitution; timing and integration matter.", "calibration": "A release announcement does not prove substitution; timing and integration matter.", "origin": "Reconciled from expansion pack entry 198; supplied source is not independent empirical validation.", "sourceIds": [ "pack:198" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:198" ] }, { "@id": "urn:business-engineer:model:0213", "@type": "Model", "id": 213, "stableId": "BE-M0213", "name": "Compute Stage and Workload Economics", "aliases": [ "The Three-Stage Token Lifecycle (The Reasoning Tax)" ], "definition": "Training, adaptation, prefill, decoding, retrieval and tool execution have different resource profiles and cost drivers.", "keyQuestion": "Which stage of the token lifecycle does this cost or moat live in, and does it scale with reasoning?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which stage of the token lifecycle does this cost or moat live in, and does it scale with reasoning?", "evidence": "Measure workload-specific throughput, latency, hardware use and cost under comparable service requirements.", "falsifier": "Different workload mixes can overturn a claimed hardware or cost advantage.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "No universal decoding ratio or annual cost-decline rate applies to every system.", "calibration": "No universal decoding ratio or annual cost-decline rate applies to every system.", "origin": "Reconciled from expansion pack entry 199; supplied source is not independent empirical validation.", "sourceIds": [ "pack:199" ], "usesConcept": [ "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:199" ] }, { "@id": "urn:business-engineer:model:0214", "@type": "Model", "id": 214, "stableId": "BE-M0214", "name": "Commercial and Capability Workload Allocation", "aliases": [ "Product Workloads vs Capability Workloads (The Inference Cage)" ], "definition": "Externally sold product workloads and internally consumed capability workloads can compete for a shared substrate; revenue visibility may bias allocation against internal capability.", "keyQuestion": "Which workload does this substrate's roadmap bend toward, and what does the bend crowd out?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which workload does this substrate's roadmap bend toward, and what does the bend crowd out?", "evidence": "Separate external and internal demand, service requirements, utilization and roadmap decisions; measure which work is delayed and the value it would create.", "falsifier": "Balanced allocation and supported internal service levels weaken a merchant-bias diagnosis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "External work can lose money and internal work can be operational. Volume and burstiness depend on the workload, not its label.", "calibration": "External work can lose money and internal work can be operational. Volume and burstiness depend on the workload, not its label.", "origin": "Reconciled from expansion pack entry 201; supplied source is not independent empirical validation.", "sourceIds": [ "pack:201" ], "usesConcept": [ "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:201" ] }, { "@id": "urn:business-engineer:model:0215", "@type": "Model", "id": 215, "stableId": "BE-M0215", "name": "Architecture Specialization Signal", "aliases": [ "The Split Is the Admission" ], "definition": "Specialized architecture may reveal an economically important workload constraint, but its value depends on real utilization and system fit.", "keyQuestion": "What does this split confess about the years the line was unified?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What does this split confess about the years the line was unified?", "evidence": "Compare representative benchmarks, total deployment costs and demand for the specialized function.", "falsifier": "A flexible alternative with comparable economics weakens the specialization advantage.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Architecture announcements are evidence of a bet, not proof of a new market regime.", "calibration": "Architecture announcements are evidence of a bet, not proof of a new market regime.", "origin": "Reconciled from expansion pack entry 202; supplied source is not independent empirical validation.", "sourceIds": [ "pack:202" ], "usesConcept": [ "urn:business-engineer:concept:constraint" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:202" ] }, { "@id": "urn:business-engineer:model:0216", "@type": "Model", "id": 216, "stableId": "BE-M0216", "name": "Iteration Access and Talent Retention", "aliases": [ "The Option to Iterate (Rationing Reprices the Bench)" ], "definition": "Access to tools, compute, users and fast feedback can affect expert learning speed and the attractiveness of an organization.", "keyQuestion": "What is this lab's queue latency, and who leaves first when it lengthens?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is this lab's queue latency, and who leaves first when it lengthens?", "evidence": "Compare time to experiment, feedback quality, autonomy and retention reasons across teams.", "falsifier": "Compensation, management or mission explaining departures better weakens the iteration-access hypothesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Do not infer individual motives from infrastructure differences alone.", "calibration": "Do not infer individual motives from infrastructure differences alone.", "origin": "Reconciled from expansion pack entry 203; supplied source is not independent empirical validation.", "sourceIds": [ "pack:203" ], "usesConcept": [ "urn:business-engineer:concept:autonomy-envelope" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:203" ] }, { "@id": "urn:business-engineer:model:0217", "@type": "Model", "id": 217, "stableId": "BE-M0217", "name": "Semantic Index Control", "aliases": [ "The Second Index (Structuring Is Ownership)" ], "definition": "A maintained representation of entities, meanings and relationships can become a valuable control point when workflows depend on its accuracy and portability.", "keyQuestion": "Who is building the graph over this corpus, from what signal, and who holds it once built?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who is building the graph over this corpus, from what signal, and who holds it once built?", "evidence": "Test semantic completeness, maintenance, provenance, query usefulness and export into an alternative runtime.", "falsifier": "Cheap reconstruction with equivalent performance weakens a durable-index advantage.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Owning a graph does not by itself create a moat or authority to act.", "calibration": "Owning a graph does not by itself create a moat or authority to act.", "origin": "Reconciled from expansion pack entry 204; supplied source is not independent empirical validation.", "sourceIds": [ "pack:204" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:204" ] }, { "@id": "urn:business-engineer:model:0218", "@type": "Model", "id": 218, "stableId": "BE-M0218", "name": "Four-Plane Intelligence Architecture", "aliases": [ "The Only Door (The Four Planes)" ], "definition": "Distinguish application interaction, context and knowledge, execution, and governance to assign responsibilities and locate failure boundaries.", "keyQuestion": "What does this agent actually read at the moment of action, and where is the policy enforced if not there?", "form": "framework", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What does this agent actually read at the moment of action, and where is the policy enforced if not there?", "evidence": "Trace a task across the four functions, including external controls and feedback.", "falsifier": "Unmapped responsibilities or boundary failures show that the chosen decomposition is incomplete.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "These are functional planes, not a universal implementation standard or chronological stack.", "calibration": "These are functional planes, not a universal implementation standard or chronological stack.", "origin": "Reconciled from expansion pack entry 205; supplied source is not independent empirical validation.", "sourceIds": [ "pack:205" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:control-plane" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:205" ] }, { "@id": "urn:business-engineer:model:0219", "@type": "Model", "id": 219, "stableId": "BE-M0219", "name": "Context and Delegation Trust Boundaries", "aliases": [ "The Attack Surface Is the Window" ], "definition": "A system's use of information and delegated actions requires explicit boundaries between instructions, untrusted content, credentials and authorized execution.", "keyQuestion": "Where are information provenance, permissions, delegated scope and external action controls enforced, and how are persistent memories handled?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where are information provenance, permissions, delegated scope and external action controls enforced, and how are persistent memories handled?", "evidence": "Inspect trust labels, permission checks, external enforcement and adversarial task tests.", "falsifier": "Unauthorized action or untrusted content overriding authority refutes the claimed boundary effectiveness.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Models contain learned information beyond the context window; enforcement need not reside inside the model.", "calibration": "Models contain learned information beyond the context window; enforcement need not reside inside the model.", "origin": "Reconciled from expansion pack entry 206; supplied source is not independent empirical validation.", "sourceIds": [ "pack:206" ], "usesConcept": [ "urn:business-engineer:concept:permission", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:206" ] }, { "@id": "urn:business-engineer:model:0220", "@type": "Model", "id": 220, "stableId": "BE-M0220", "name": "Query and Vocabulary Fit", "aliases": [ "The Two Readers" ], "definition": "A knowledge store's representation and retrieval methods determine which human or agent questions it can answer accurately and efficiently; domain-approved vocabulary helps preserve business meaning.", "keyQuestion": "Is this store shaped for the question the agent asks, and did the business sign the vocabulary it uses?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this store shaped for the question the agent asks, and did the business sign the vocabulary it uses?", "evidence": "Compare key lookup, similarity, reference and graph traversal on representative queries; measure answer quality, latency and cost and obtain domain-owner review of the vocabulary.", "falsifier": "Equivalent performance from a simpler representation or domain disagreement about the encoded meaning weakens the proposed semantic design.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Humans and agents can use several query forms. Token-cost comparisons are workload-specific; a business-approved vocabulary is neither sufficient validation nor a requirement for a graph to be technically an ontology.", "calibration": "Humans and agents can use several query forms. Token-cost comparisons are workload-specific; a business-approved vocabulary is neither sufficient validation nor a requirement for a graph to be technically an ontology.", "origin": "Reconciled from expansion pack entry 207; supplied source is not independent empirical validation.", "sourceIds": [ "pack:207" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:207" ] }, { "@id": "urn:business-engineer:model:0221", "@type": "Model", "id": 221, "stableId": "BE-M0221", "name": "Metric Optimization Pressure", "aliases": [ "Goodhart Is the Physics", "Growth Goodhart (The Slop Flood)" ], "definition": "Optimizing a proxy can reduce its usefulness when behavior exploits the gap between the measure and the intended outcome.", "keyQuestion": "Can the thing being optimized see the measure I am using to judge it?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Can the thing being optimized see the measure I am using to judge it?", "evidence": "Compare proxy gains with independent outcome measures, adversarial cases and distribution shifts.", "falsifier": "Sustained outcome improvement on fresh cases weakens a metric-gaming explanation.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Goodhart effects, contamination, sycophancy and deceptive behavior are distinct hypotheses, not one physical law.", "calibration": "Goodhart effects, contamination, sycophancy and deceptive behavior are distinct hypotheses, not one physical law.", "origin": "Reconciled from expansion pack entry 208; supplied source is not independent empirical validation.", "applications": [ { "sourceId": "pack:217", "name": "Growth Metrics and Real Outcomes", "definition": "Growth optimization can reward activity that raises a proxy while failing to improve durable customer or economic outcomes.", "evidence": "Compare activation or usage metrics with retention, contribution and independently accepted value.", "falsifier": "Sustained improvements in those outcomes weaken a proxy-gaming diagnosis.", "limits": "A disappointing business result need not imply intentional gaming.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "pack:208", "pack:217" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:208", "urn:business-engineer:source-entry:pack:217" ], "instruments": [ "urn:business-engineer:instrument:suite" ] }, { "@id": "urn:business-engineer:model:0222", "@type": "Model", "id": 222, "stableId": "BE-M0222", "name": "Independent Evaluation Standard", "aliases": [ "The Frozen Suite" ], "definition": "A system needs an outcome standard and evaluation process sufficiently independent of its optimization process to detect real failures.", "keyQuestion": "Is there a referee this loop cannot see, and was it frozen before the loop started?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is there a referee this loop cannot see, and was it frozen before the loop started?", "evidence": "Use versioned holdouts, fresh cases, contamination checks, adversarial tests and live outcome monitoring.", "falsifier": "High suite performance with repeated live failure weakens the suite's validity.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A frozen or secret suite alone is insufficient; independence is proportionate to risk and may include external review.", "calibration": "A frozen or secret suite alone is insufficient; independence is proportionate to risk and may include external review.", "origin": "Reconciled from expansion pack entry 209; supplied source is not independent empirical validation.", "sourceIds": [ "pack:209" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:suite", "urn:business-engineer:concept:independent-evaluation" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:209" ], "instruments": [ "urn:business-engineer:instrument:suite", "urn:business-engineer:instrument:drift" ] }, { "@id": "urn:business-engineer:model:0223", "@type": "Model", "id": 223, "stableId": "BE-M0223", "name": "Behavioral Acceptance Specification", "aliases": [ "Evaluation Is the Specification (The Model Chosen Last)" ], "definition": "Specify observable acceptable behavior, failure handling and authority boundaries before treating a demonstration as successful delivery.", "keyQuestion": "Does this product have a specification a model can be graded against, and was the model chosen before or after it existed?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this product have a specification a model can be graded against, and was the model chosen before or after it existed?", "evidence": "Write representative cases, thresholds, exception paths and acceptance responsibilities before the proof.", "falsifier": "Repeated disagreement among qualified evaluators exposes an underspecified standard.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Requirements and feasibility co-evolve; model selection need not wait until the last week.", "calibration": "Requirements and feasibility co-evolve; model selection need not wait until the last week.", "origin": "Reconciled from expansion pack entry 210; supplied source is not independent empirical validation.", "sourceIds": [ "pack:210" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:210" ], "instruments": [ "urn:business-engineer:instrument:deploy", "urn:business-engineer:instrument:suite" ] }, { "@id": "urn:business-engineer:model:0224", "@type": "Model", "id": 224, "stableId": "BE-M0224", "name": "Governed Decision Loop", "aliases": [ "The Loop as the Unit" ], "definition": "Connect a stated outcome, evaluation standard, authorized execution and observed feedback in a repeatable loop with an accountable owner.", "keyQuestion": "Is this a loop the firm owns, or a person doing the loop's job by hand?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08", "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this a loop the firm owns, or a person doing the loop's job by hand?", "evidence": "Trace outcome, decision, action, evidence, exception and update for representative cases.", "falsifier": "Unowned exceptions or missing feedback break the claim of a governed loop.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Automation is optional; the loop can include human decisions and external controls.", "calibration": "Automation is optional; the loop can include human decisions and external controls.", "origin": "Reconciled from expansion pack entry 212; supplied source is not independent empirical validation.", "sourceIds": [ "pack:212" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:212" ], "instruments": [ "urn:business-engineer:instrument:deploy", "urn:business-engineer:instrument:charter" ] }, { "@id": "urn:business-engineer:model:0225", "@type": "Model", "id": 225, "stableId": "BE-M0225", "name": "Engineered Unit Economics", "aliases": [ "Gross Margin as a Design Outcome" ], "definition": "Operational design can change unit cost through routing, caching, batching, retrieval, review and exception handling.", "keyQuestion": "Which of the four margin levers has this company pulled, and which is still available?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of the four margin levers has this company pulled, and which is still available?", "evidence": "Measure each intervention's incremental cost, accepted quality and realized volume against a baseline.", "falsifier": "Savings erased by maintenance, rework or quality loss weaken the margin-improvement thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Available levers are not realized savings; report implementation costs and dates.", "calibration": "Available levers are not realized savings; report implementation costs and dates.", "origin": "Reconciled from expansion pack entry 213; supplied source is not independent empirical validation.", "sourceIds": [ "pack:213" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:baseline", "urn:business-engineer:concept:adjudication", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:213" ] }, { "@id": "urn:business-engineer:model:0226", "@type": "Model", "id": 226, "stableId": "BE-M0226", "name": "Usage-Tail Pricing", "aliases": [ "Pricing as a Finance Instrument (Price the Tail)" ], "definition": "Heavy or difficult usage can dominate service cost, making average-user economics an unreliable pricing guide.", "keyQuestion": "Does this price track the work done and the tail that does it, or the chairs?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this price track the work done and the tail that does it, or the chairs?", "evidence": "Model the cost distribution, correlated peaks, retries and cohort contribution rather than only the mean.", "falsifier": "Thin stable tails and predictable usage weaken the case for special tail controls.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Caps and pricing changes can reduce customer value; test incentives and fairness of the chosen unit.", "calibration": "Caps and pricing changes can reduce customer value; test incentives and fairness of the chosen unit.", "origin": "Reconciled from expansion pack entry 214; supplied source is not independent empirical validation.", "sourceIds": [ "pack:214" ], "usesConcept": [ "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:214" ] }, { "@id": "urn:business-engineer:model:0227", "@type": "Model", "id": 227, "stableId": "BE-M0227", "name": "Hybrid Pricing Transition", "aliases": [ "Outcome Pricing Is an End State (The Hybrid Is the Transition)" ], "definition": "Combine subscription, usage and outcome-linked charges when measurement, attribution and risk allocation support different units at different stages.", "keyQuestion": "Which rung of the seat-to-outcome ramp is this contract on, and who is carrying the guarantee's cost?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which rung of the seat-to-outcome ramp is this contract on, and who is carrying the guarantee's cost?", "evidence": "Test buyer acceptance, margin volatility, attribution disputes and incentives under each pricing mix.", "falsifier": "Stable economics and incentives in a hybrid can refute the need to reach pure outcome pricing.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Outcome pricing is a possible design, not an inevitable end state.", "calibration": "Outcome pricing is a possible design, not an inevitable end state.", "origin": "Reconciled from expansion pack entry 215; supplied source is not independent empirical validation.", "sourceIds": [ "pack:215" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:215" ] }, { "@id": "urn:business-engineer:model:0228", "@type": "Model", "id": 228, "stableId": "BE-M0228", "name": "Valuation Assumption Audit", "aliases": [ "The Multiple Comes Last (The Five Broken Assumptions)" ], "definition": "Build a valuation from reconciled revenue, cost, durability, control, funding and failure assumptions before using a market multiple as a cross-check.", "keyQuestion": "Which of the five assumptions is this valuation still making, and in which direction does the error run?", "form": "framework", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of the five assumptions is this valuation still making, and in which direction does the error run?", "evidence": "Document a cash-flow bridge, competing valuation and sensitivity to the assumptions that explain the gap.", "falsifier": "An unresolved counting or cash-flow inconsistency invalidates precision in the headline value.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The nine-question order is a practical workflow, not the only valid valuation method.", "calibration": "The nine-question order is a practical workflow, not the only valid valuation method.", "origin": "Reconciled from expansion pack entry 220; supplied source is not independent empirical validation.", "sourceIds": [ "pack:220" ], "usesConcept": [ "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:220" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0229", "@type": "Model", "id": 229, "stableId": "BE-M0229", "name": "Revenue Counting Boundary", "aliases": [ "The Counted Top Line" ], "definition": "Define whether the analysis counts reported company revenue, gross transactions or final-customer demand, then reconcile the chosen boundary.", "keyQuestion": "What is this company's counted top line, and what is the ratio of counted to reported?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is this company's counted top line, and what is the ratio of counted to reported?", "evidence": "Bridge tiers, payer classes, gross versus net treatment and run-rate versus realized annual revenue.", "falsifier": "A boundary-consistent bridge can refute an apparent overstatement caused only by unlike measures.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Partner-funded revenue may be recognized legitimately; demand independence is a separate analysis.", "calibration": "Partner-funded revenue may be recognized legitimately; demand independence is a separate analysis.", "origin": "Reconciled from expansion pack entry 221; supplied source is not independent empirical validation.", "sourceIds": [ "pack:221" ], "usesConcept": [ "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:221" ], "instruments": [ "urn:business-engineer:instrument:reconciliation", "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0230", "@type": "Model", "id": 230, "stableId": "BE-M0230", "name": "Durable and Perishable Value", "aliases": [ "The Residual" ], "definition": "Separate cash flows supported by persistent assets and relationships from those exposed to likely substitution or rapid decay.", "keyQuestion": "What fraction of this company survives the next release, and is the multiple being applied to that fraction or to the whole?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What fraction of this company survives the next release, and is the multiple being applied to that fraction or to the whole?", "evidence": "Model renewal, switching, replacement and reinvestment under explicit durability scenarios.", "falsifier": "Durable retention despite anticipated substitution weakens the assumed decay rate.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Durability is a spectrum; terminal value also depends on reinvestment, competition and sustainable growth.", "calibration": "Durability is a spectrum; terminal value also depends on reinvestment, competition and sustainable growth.", "origin": "Reconciled from expansion pack entry 222; supplied source is not independent empirical validation.", "sourceIds": [ "pack:222" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:residual-value" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:222" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0231", "@type": "Model", "id": 231, "stableId": "BE-M0231", "name": "Enterprise Value and Obligation Reconciliation", "aliases": [ "The EV Bridge With Hidden Piers" ], "definition": "Reconcile operating value with equity and other claims, cash and non-operating assets, and separately identified contingent or debt-like exposures.", "keyQuestion": "Which claims, non-operating assets and contingent obligations reconcile operating value to equity value without double counting?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which claims, non-operating assets and contingent obligations reconcile operating value to equity value without double counting?", "evidence": "Bridge equity, debt, preferred claims, noncontrolling interests and relevant cash with consistent DCF and lease treatment.", "falsifier": "An obligation already included in cash flows or debt exposes double counting if added again.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Not every purchase commitment is debt; avoid subtracting cash or adding liabilities twice.", "calibration": "Not every purchase commitment is debt; avoid subtracting cash or adding liabilities twice.", "origin": "Reconciled from expansion pack entry 223; supplied source is not independent empirical validation.", "sourceIds": [ "pack:223" ], "usesConcept": [ "urn:business-engineer:concept:obligation", "urn:business-engineer:concept:exposure" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:223" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0232", "@type": "Model", "id": 232, "stableId": "BE-M0232", "name": "Failure Scenario Valuation", "aliases": [ "The Worthless Cases, Weighted" ], "definition": "Identify mechanisms that can destroy or sharply reduce equity value and model their triggers, timing, recovery and probability where supportable.", "keyQuestion": "What kills this company, what is the trigger, and what is the probability-weighted value once that case is in the sum?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What kills this company, what is the trigger, and what is the probability-weighted value once that case is in the sum?", "evidence": "Stress liquidity, substitution, concentration and asset recovery with explicit correlated assumptions.", "falsifier": "Adequate recovery or resilient cash flow can refute a literal worthless scenario.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Three cases is a drafting aid; probabilities must be supported and scenarios must not be double counted.", "calibration": "Three cases is a drafting aid; probabilities must be supported and scenarios must not be double counted.", "origin": "Reconciled from expansion pack entry 224; supplied source is not independent empirical validation.", "sourceIds": [ "pack:224" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:counting-boundary" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:224" ], "instruments": [ "urn:business-engineer:instrument:valuation" ], "modes": [ "urn:business-engineer:mode:valuation" ] }, { "@id": "urn:business-engineer:model:0233", "@type": "Model", "id": 233, "stableId": "BE-M0233", "name": "Transaction Perimeter Read", "aliases": [ "The Acqui-Hire Read" ], "definition": "A transaction price is interpretable only after identifying the assets, liabilities, rights, control and contingencies actually transferred.", "keyQuestion": "In this deal, what did the buyer pay for and what did it leave behind, and what does that say about the residual of the whole company?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D05" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "In this deal, what did the buyer pay for and what did it leave behind, and what does that say about the residual of the whole company?", "evidence": "Read the deal perimeter, consideration, assumed debt, earnouts and retained obligations.", "falsifier": "Material excluded assets or contingent payments undermine a simple headline-price comparison.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "An announced valuation is not always cash consideration or enterprise value.", "calibration": "An announced valuation is not always cash consideration or enterprise value.", "origin": "Reconciled from expansion pack entry 226; supplied source is not independent empirical validation.", "sourceIds": [ "pack:226" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:obligation" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:226" ] }, { "@id": "urn:business-engineer:model:0234", "@type": "Model", "id": 234, "stableId": "BE-M0234", "name": "Buyer and Seller Repetition Asymmetry", "aliases": [ "The Asymmetry" ], "definition": "A repeat seller may possess more information and process experience than an occasional buyer, affecting negotiation and evaluation quality.", "keyQuestion": "What instrument does this buyer hold that substitutes for the repetitions the seller has and it does not?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What instrument does this buyer hold that substitutes for the repetitions the seller has and it does not?", "evidence": "Compare access to benchmarks, reference cases, contract expertise and independent verification.", "falsifier": "An experienced buyer with credible alternatives can reverse the presumed asymmetry.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Do not infer bad faith from experience; design the process to reduce information gaps.", "calibration": "Do not infer bad faith from experience; design the process to reduce information gaps.", "origin": "Reconciled from expansion pack entry 229; supplied source is not independent empirical validation.", "sourceIds": [ "pack:229" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:229" ], "modes": [ "urn:business-engineer:mode:buyer" ] }, { "@id": "urn:business-engineer:model:0235", "@type": "Model", "id": 235, "stableId": "BE-M0235", "name": "Buyer Qualification Framework", "aliases": [ "VERIFIED (The Buyer's Qualification)" ], "definition": "Evaluate verification, economics, rights, incentives, feasibility, independence, exposure and drift before and during a supplier relationship.", "keyQuestion": "Which letters of VERIFIED hold an artifact, and which is the one nobody checked?", "form": "framework", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which letters of VERIFIED hold an artifact, and which is the one nobody checked?", "evidence": "Require a named owner, dated artifact and disposition for each VERIFIED step.", "falsifier": "Missing artifacts or failed mandatory gates refute a claim of completed qualification.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Price can compensate some commercial risks, but cannot cure absent required authority or a non-negotiable safety or legal gate.", "calibration": "Price can compensate some commercial risks, but cannot cure absent required authority or a non-negotiable safety or legal gate.", "origin": "Reconciled from expansion pack entry 230; supplied source is not independent empirical validation.", "sourceIds": [ "pack:230" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:drift" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:230" ], "instruments": [ "urn:business-engineer:instrument:verified" ], "modes": [ "urn:business-engineer:mode:buyer" ] }, { "@id": "urn:business-engineer:model:0236", "@type": "Model", "id": 236, "stableId": "BE-M0236", "name": "Evaluation Provenance and Buyer Control", "aliases": [ "Procurement Theater" ], "definition": "Determine who selected, prepared and scored evaluation cases and which conditions differ from real buyer use.", "keyQuestion": "Which part of this evaluation could the vendor have staged, and which part ran on my floor against my referee?", "form": "diagnostic", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which part of this evaluation could the vendor have staged, and which part ran on my floor against my referee?", "evidence": "Run buyer-controlled cases on representative systems with staged and unstaged conditions separated.", "falsifier": "Comparable results on fresh buyer cases weaken a procurement-theater concern.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Vendor involvement can be useful; disclose it and preserve independent acceptance authority.", "calibration": "Vendor involvement can be useful; disclose it and preserve independent acceptance authority.", "origin": "Reconciled from expansion pack entry 231; supplied source is not independent empirical validation.", "sourceIds": [ "pack:231" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:suite", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:independent-evaluation" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:231" ], "instruments": [ "urn:business-engineer:instrument:verified" ], "modes": [ "urn:business-engineer:mode:buyer" ] }, { "@id": "urn:business-engineer:model:0237", "@type": "Model", "id": 237, "stableId": "BE-M0237", "name": "Governed Fast Intake", "aliases": [ "Fast Yes With Clean Title" ], "definition": "Provide a rapid, visible path for evaluating and approving tools so that governance does not simply drive work into unobserved channels.", "keyQuestion": "Can this firm say yes in days while keeping clear title to what the purchase will compound?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Can this firm say yes in days while keeping clear title to what the purchase will compound?", "evidence": "Measure intake time, shadow usage, incidents, adoption and coverage of approved paths.", "falsifier": "Long queues with continued shadow use refute the claim of effective governed intake.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Speed cannot waive mandatory authorization, security or legal requirements.", "calibration": "Speed cannot waive mandatory authorization, security or legal requirements.", "origin": "Reconciled from expansion pack entry 232; supplied source is not independent empirical validation.", "sourceIds": [ "pack:232" ], "usesConcept": [ "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:control-plane" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:232" ] }, { "@id": "urn:business-engineer:model:0238", "@type": "Model", "id": 238, "stableId": "BE-M0238", "name": "Deployment Control Inheritance", "aliases": [ "The Hand That Wires the Harness Chooses the Landlord" ], "definition": "Defaults chosen during implementation can become durable control points over identity, data, evaluation, workflows and future change.", "keyQuestion": "Who wired this loop, and whose walls does its exhaust accumulate inside?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who wired this loop, and whose walls does its exhaust accumulate inside?", "evidence": "Inventory deployed accounts, ownership, permissions, repositories, standards and export paths at handover.", "falsifier": "Buyer-controlled configuration and rehearsed migration weaken the inherited-capture thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Initial convenience does not establish permanent dependence; contracts and technical transfer both matter.", "calibration": "Initial convenience does not establish permanent dependence; contracts and technical transfer both matter.", "origin": "Reconciled from expansion pack entry 234; supplied source is not independent empirical validation.", "sourceIds": [ "pack:234" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:234" ] }, { "@id": "urn:business-engineer:model:0239", "@type": "Model", "id": 239, "stableId": "BE-M0239", "name": "Subsidy and Substitution Timing", "aliases": [ "The Two-Hinge Window" ], "definition": "A subsidy can accelerate adoption before dependency forms, while later substitution or repricing changes the relationship's economics.", "keyQuestion": "Which hinge is this firm timing against, the subsidy that expires or the feasibility that does not?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which hinge is this firm timing against, the subsidy that expires or the feasibility that does not?", "evidence": "Compare subsidy expiry, integration milestones, available alternatives and repricing rights.", "falsifier": "Portable deployments and sustained competitive pricing weaken a delayed-capture hypothesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Introductory discounts are not proof of an intended lock-in strategy.", "calibration": "Introductory discounts are not proof of an intended lock-in strategy.", "origin": "Reconciled from expansion pack entry 235; supplied source is not independent empirical validation.", "sourceIds": [ "pack:235" ], "usesConcept": [ "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:clock" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:235" ] }, { "@id": "urn:business-engineer:model:0240", "@type": "Model", "id": 240, "stableId": "BE-M0240", "name": "Portability-Aligned Delivery", "aliases": [ "The Independence Integrator (The Double Objective)" ], "definition": "A service provider can create value by leaving the client with usable artifacts, skills and a priced exit rather than maximizing dependence.", "keyQuestion": "Does this engagement leave the enterprise able to migrate in six weeks, and who gets paid when it can?", "form": "archetype", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this engagement leave the enterprise able to migrate in six weeks, and who gets paid when it can?", "evidence": "Inspect retained artifacts, client competence, recurring support needs and exercised alternate execution.", "falsifier": "A technically documented exit requiring a practical rebuild weakens the independence claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Independence has maintenance costs; a services relationship can remain economically sensible.", "calibration": "Independence has maintenance costs; a services relationship can remain economically sensible.", "origin": "Reconciled from expansion pack entry 236; supplied source is not independent empirical validation.", "sourceIds": [ "pack:236" ], "usesConcept": [ "urn:business-engineer:concept:portability", "urn:business-engineer:concept:runtime" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:236" ] }, { "@id": "urn:business-engineer:model:0241", "@type": "Model", "id": 241, "stableId": "BE-M0241", "name": "Layered Dependency Audit", "aliases": [ "The Three Cages" ], "definition": "Assess dependency separately in data, semantics, runtime, model, control, commercial terms and operating skills.", "keyQuestion": "In which of the three cages is this enterprise, and is the sovereignty it was sold the customer's or the vendor's?", "form": "framework", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "In which of the three cages is this enterprise, and is the sovereignty it was sold the customer's or the vendor's?", "evidence": "Perform a workload-specific exit and replacement inventory with rights, costs and timing per layer.", "falsifier": "Successful transfer of one layer does not refute dependence elsewhere; a complete alternative path does.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Open source at one layer does not make the whole system independent.", "calibration": "Open source at one layer does not make the whole system independent.", "origin": "Reconciled from expansion pack entry 237; supplied source is not independent empirical validation.", "sourceIds": [ "pack:237" ], "usesConcept": [ "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:clock", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:237" ], "instruments": [ "urn:business-engineer:instrument:capture", "urn:business-engineer:instrument:priced-exit" ], "modes": [ "urn:business-engineer:mode:capture" ] }, { "@id": "urn:business-engineer:model:0242", "@type": "Model", "id": 242, "stableId": "BE-M0242", "name": "Enterprise as Distribution Complement", "aliases": [ "The Enterprise Edge as Distribution" ], "definition": "An enterprise can supply demand, workflow access and trusted distribution that help a technology provider commercialize a capability.", "keyQuestion": "Which vendor's silicon does this enterprise stack distribute, and who wrapped it into something buyable?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which vendor's silicon does this enterprise stack distribute, and who wrapped it into something buyable?", "evidence": "Trace the provider's incremental reach, conversion and retained control through the enterprise relationship.", "falsifier": "Little incremental demand or readily substitutable access weakens the distribution-complement thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The enterprise may capture substantial value too; dependence must be assessed in both directions.", "calibration": "The enterprise may capture substantial value too; dependence must be assessed in both directions.", "origin": "Reconciled from expansion pack entry 238; supplied source is not independent empirical validation.", "sourceIds": [ "pack:238" ], "usesConcept": [ "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:238" ] }, { "@id": "urn:business-engineer:model:0243", "@type": "Model", "id": 243, "stableId": "BE-M0243", "name": "Relative Productivity Advantage", "aliases": [ "The Neutral Gain" ], "definition": "An absolute productivity gain does not ensure competitive advantage if peers gain similarly or customers capture the savings.", "keyQuestion": "Your people are faster. Is the firm ahead, and by what asymmetry?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D02" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Your people are faster. Is the firm ahead, and by what asymmetry?", "evidence": "Compare quality-adjusted throughput, cost, price and share against a relevant peer or counterfactual.", "falsifier": "Durable relative improvement and retained margin can support an advantage beyond a neutral gain.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Industry-wide gains can still benefit customers and workers without creating excess firm profits.", "calibration": "Industry-wide gains can still benefit customers and workers without creating excess firm profits.", "origin": "Reconciled from expansion pack entry 239; supplied source is not independent empirical validation.", "sourceIds": [ "pack:239" ], "usesConcept": [ "urn:business-engineer:concept:claim", "urn:business-engineer:concept:counter-model" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:239" ], "instruments": [ "urn:business-engineer:instrument:climb" ], "modes": [ "urn:business-engineer:mode:organization" ] }, { "@id": "urn:business-engineer:model:0244", "@type": "Model", "id": 244, "stableId": "BE-M0244", "name": "Productivity Transmission Across Scales", "aliases": [ "The Ascent Through Scales" ], "definition": "Task gains affect firm performance only when workflow, organizational and business-model constraints allow the gains to propagate.", "keyQuestion": "At which scale did this firm's gain stop climbing, and what would carry it one level up?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "At which scale did this firm's gain stop climbing, and what would carry it one level up?", "evidence": "Measure task time, end-to-end throughput, operating outcomes and economic capture on aligned dates.", "falsifier": "A task improvement with no downstream change identifies a broken transmission link.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Task, workflow, firm and market are analytical scales, not a mandatory maturity sequence.", "calibration": "Task, workflow, firm and market are analytical scales, not a mandatory maturity sequence.", "origin": "Reconciled from expansion pack entry 240; supplied source is not independent empirical validation.", "sourceIds": [ "pack:240" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:240" ], "instruments": [ "urn:business-engineer:instrument:climb", "urn:business-engineer:instrument:gauge-page" ], "modes": [ "urn:business-engineer:mode:organization" ] }, { "@id": "urn:business-engineer:model:0245", "@type": "Model", "id": 245, "stableId": "BE-M0245", "name": "Federated Discovery and Central Coordination", "aliases": [ "Edges Find and Cannot Choose; Center Chooses and Cannot Find" ], "definition": "Local experimentation can coexist with shared standards, reusable infrastructure and explicit responsibility for common constraints.", "keyQuestion": "What is this firm's conversion time from an edge discovery to a governed loop, and who owns the paved road?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "What is this firm's conversion time from an edge discovery to a governed loop, and who owns the paved road?", "evidence": "Compare discovery speed, duplication, paved-path use, exceptions and cross-team reuse.", "falsifier": "Central delay or uncontrolled fragmentation can refute the chosen balance.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The appropriate center varies with risk, heterogeneity, scale and capabilities.", "calibration": "The appropriate center varies with risk, heterogeneity, scale and capabilities.", "origin": "Reconciled from expansion pack entry 241; supplied source is not independent empirical validation.", "sourceIds": [ "pack:241" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:distribution", "urn:business-engineer:concept:adjudication", "urn:business-engineer:concept:paved-road" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:241" ], "instruments": [ "urn:business-engineer:instrument:climb" ], "modes": [ "urn:business-engineer:mode:organization" ] }, { "@id": "urn:business-engineer:model:0246", "@type": "Model", "id": 246, "stableId": "BE-M0246", "name": "Complementary Organizational Change", "aliases": [ "Installation Is the Entry Fee, Reorganization Is the Harvest" ], "definition": "Technology creates more value when workflows, incentives, skills and decision rights are adapted to use it effectively.", "keyQuestion": "Has this firm installed the technology or rebuilt the floor around what it makes cheap?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Has this firm installed the technology or rebuilt the floor around what it makes cheap?", "evidence": "Compare similar deployments with different complementary changes and account for selection effects.", "falsifier": "Equal outcomes without the proposed complement weaken its claimed necessity.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Complementarity does not imply that every organization needs a full reorganization first.", "calibration": "Complementarity does not imply that every organization needs a full reorganization first.", "origin": "Reconciled from expansion pack entry 242; supplied source is not independent empirical validation.", "sourceIds": [ "pack:242" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:process-specification" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:242" ] }, { "@id": "urn:business-engineer:model:0247", "@type": "Model", "id": 247, "stableId": "BE-M0247", "name": "Task Automation and Augmentation", "aliases": [ "Automation or Enhancement Is a Deployment Choice" ], "definition": "Analyze which tasks can be automated, assisted or redesigned while distinguishing task changes from whole-job outcomes.", "keyQuestion": "On this task line, which spans are automated, which enhanced, and where does the next person enter?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "On this task line, which spans are automated, which enhanced, and where does the next person enter?", "evidence": "Observe quality, demand, new tasks, supervision and labor allocation before and after adoption.", "falsifier": "Persisting expert requirements or expanded demand can overturn simple replacement forecasts.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A task capability demonstration is not a headcount prediction.", "calibration": "A task capability demonstration is not a headcount prediction.", "origin": "Reconciled from expansion pack entry 243; supplied source is not independent empirical validation.", "sourceIds": [ "pack:243" ], "usesConcept": [ "urn:business-engineer:concept:baseline" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:243" ] }, { "@id": "urn:business-engineer:model:0248", "@type": "Model", "id": 248, "stableId": "BE-M0248", "name": "Human and Agent Capacity Envelope", "aliases": [ "The Ratio Rule (Push Until the Gate Bends)" ], "definition": "Set a team's span of agent-supported work according to measured quality, exception load, supervision and accountability.", "keyQuestion": "Is this ratio backed by a measured gate, and at what ratio did the gate last bend?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this ratio backed by a measured gate, and at what ratio did the gate last bend?", "evidence": "Measure accepted throughput, incidents, adjudication burden and response capacity before changing ratios.", "falsifier": "Rising unresolved exceptions or quality loss refutes a claimed safe expansion of span.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "No universal human-to-agent ratio is supplied; headcount alone is not a performance gauge.", "calibration": "No universal human-to-agent ratio is supplied; headcount alone is not a performance gauge.", "origin": "Reconciled from expansion pack entry 244; supplied source is not independent empirical validation.", "sourceIds": [ "pack:244" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:244" ], "instruments": [ "urn:business-engineer:instrument:climb" ], "modes": [ "urn:business-engineer:mode:organization" ] }, { "@id": "urn:business-engineer:model:0249", "@type": "Model", "id": 249, "stableId": "BE-M0249", "name": "Organizational Complementarity Moat", "aliases": [ "Organization Design Is Moat Design" ], "definition": "Residue, a deliberate ownership boundary, coordination capital and default status with machine buyers are four proposed sources of organizational advantage that may reinforce one another.", "keyQuestion": "Which of residue, ownership, coordination and buyer preference produces measurable advantage, and how do the mechanisms interact?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D02" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of residue, ownership, coordination and buyer preference produces measurable advantage, and how do the mechanisms interact?", "evidence": "Measure usable learning, exercised control and exit, coordinated throughput, buyer selection and the difficulty of replicating their combination.", "falsifier": "Easy replication, unused residue, expensive control or no buyer preference weakens the moat claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The proposed cost-to-speed-to-optionality-to-moat sequence is not a strict law; verify the links and account for complexity and maintenance.", "calibration": "The proposed cost-to-speed-to-optionality-to-moat sequence is not a strict law; verify the links and account for complexity and maintenance.", "origin": "Reconciled from expansion pack entry 246; supplied source is not independent empirical validation.", "sourceIds": [ "pack:246" ], "usesConcept": [ "urn:business-engineer:concept:residue", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:coordination-capital", "urn:business-engineer:concept:machine-buyer-preference" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:246" ] }, { "@id": "urn:business-engineer:model:0250", "@type": "Model", "id": 250, "stableId": "BE-M0250", "name": "Apprenticeship Erosion and Redesign", "aliases": [ "The Entry Point Moves", "The Missing Rung" ], "definition": "Automating routine work can remove the practice through which newcomers developed judgment, requiring a deliberate replacement learning path.", "keyQuestion": "Where in this firm is judgment being built now that the stairs are gone, and is it enforced by structure or by exhortation?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where in this firm is judgment being built now that the stairs are gone, and is it enforced by structure or by exhortation?", "evidence": "Track exposure to cases, feedback quality, error correction and independent competence over time.", "falsifier": "Equivalent skill development through existing paths weakens the claim that the first rung is missing.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Ninety days is a configurable program target, not a validated universal time to competence.", "calibration": "Ninety days is a configurable program target, not a validated universal time to competence.", "origin": "Reconciled from expansion pack entry 247; supplied source is not independent empirical validation.", "applications": [ { "sourceId": "pack:254", "name": "Moving the Entry Point", "definition": "Redesign junior entry roles around supervised operation, evaluation and learning when routine production tasks are automated.", "evidence": "Assess case-based learning, demonstrated judgment and opportunities to progress beyond tool operation.", "falsifier": "Strong existing apprenticeship outcomes weaken the need to replace the entry path.", "limits": "Automation can both remove and create jobs; no universal employment direction follows.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "pack:247", "pack:254" ], "usesConcept": [ "urn:business-engineer:concept:exposure", "urn:business-engineer:concept:independent-evaluation" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:247", "urn:business-engineer:source-entry:pack:254" ], "instruments": [ "urn:business-engineer:instrument:climb" ], "modes": [ "urn:business-engineer:mode:organization" ] }, { "@id": "urn:business-engineer:model:0251", "@type": "Model", "id": 251, "stableId": "BE-M0251", "name": "Exception Judgment and Standard Evolution", "aliases": [ "The Judgment Layer" ], "definition": "Experts can create lasting value by resolving novel exceptions and converting justified decisions into improved standards.", "keyQuestion": "Who in this firm can say what the standard should be when it is silent, and does each of their judgments become a case?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who in this firm can say what the standard should be when it is silent, and does each of their judgments become a case?", "evidence": "Trace exceptions through adjudication, rationale, standard changes and recurrence reduction.", "falsifier": "Unchanged standards or repeated failures weaken a claim that expert judgment is compounding.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Not every exception should become a rule; preserve context and dissent where uncertainty remains.", "calibration": "Not every exception should become a rule; preserve context and dissent where uncertainty remains.", "origin": "Reconciled from expansion pack entry 248; supplied source is not independent empirical validation.", "sourceIds": [ "pack:248" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:248" ] }, { "@id": "urn:business-engineer:model:0252", "@type": "Model", "id": 252, "stableId": "BE-M0252", "name": "Expert Seeding Investment", "aliases": [ "The Seed" ], "definition": "Expert-designed examples and acceptance cases can provide initial structure for a system before operating feedback is available.", "keyQuestion": "Who seeded this loop, how many cases did they adjudicate, and did they sign the vocabulary?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who seeded this loop, how many cases did they adjudicate, and did they sign the vocabulary?", "evidence": "Measure coverage, inter-rater agreement, held-out performance and the value of additional cases.", "falsifier": "Poor transfer to fresh cases weakens the seed set's usefulness.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "A target such as fifty seed cases is illustrative; diversity and difficulty matter more than a fixed count.", "calibration": "A target such as fifty seed cases is illustrative; diversity and difficulty matter more than a fixed count.", "origin": "Reconciled from expansion pack entry 249; supplied source is not independent empirical validation.", "sourceIds": [ "pack:249" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:suite" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:249" ] }, { "@id": "urn:business-engineer:model:0253", "@type": "Model", "id": 253, "stableId": "BE-M0253", "name": "Expert Leverage Economics", "aliases": [ "Leverage Is Loops per Senior" ], "definition": "An expert can support more valuable work through reusable knowledge and governed execution when review and exception burdens remain manageable.", "keyQuestion": "How many loops does each senior in this firm sign, and is the price attached to the outcome or the hour?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "How many loops does each senior in this firm sign, and is the price attached to the outcome or the hour?", "evidence": "Compare accepted outcomes, quality, review time, total cost and client value across increasing scope.", "falsifier": "Rising rework or diluted judgment can erase the apparent leverage.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Revenue per employee alone omits capital, contractors, pricing and quality.", "calibration": "Revenue per employee alone omits capital, contractors, pricing and quality.", "origin": "Reconciled from expansion pack entry 250; supplied source is not independent empirical validation.", "sourceIds": [ "pack:250" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:250" ] }, { "@id": "urn:business-engineer:model:0254", "@type": "Model", "id": 254, "stableId": "BE-M0254", "name": "Four Ownerships of AI Work", "aliases": [ "The Four Ownerships" ], "definition": "Assign accountability for the substrate, the junctions, the acceptance standard and the exit, with budget authority and the right to stop where necessary.", "keyQuestion": "Who is accountable for the substrate, the junctions, the standard and the exit, with what budget and stop authority?", "form": "framework", "domains": [ "urn:business-engineer:domain:D09", "urn:business-engineer:domain:D07" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Who is accountable for the substrate, the junctions, the standard and the exit, with what budget and stop authority?", "evidence": "Name the decision right, owner, escalation and supporting artifacts for each ownership.", "falsifier": "Conflicting owners or unowned decisions refute a complete accountability design.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "These are rights and responsibilities, not four mandatory executive titles.", "calibration": "These are rights and responsibilities, not four mandatory executive titles.", "origin": "Reconciled from expansion pack entry 251; supplied source is not independent empirical validation.", "sourceIds": [ "pack:251" ], "usesConcept": [ "urn:business-engineer:concept:junction", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:portability", "urn:business-engineer:concept:substrate" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:251" ], "instruments": [ "urn:business-engineer:instrument:climb", "urn:business-engineer:instrument:charter", "urn:business-engineer:instrument:responsibility-grid" ], "modes": [ "urn:business-engineer:mode:roles" ] }, { "@id": "urn:business-engineer:model:0255", "@type": "Model", "id": 255, "stableId": "BE-M0255", "name": "Executive Role Reconfiguration", "aliases": [ "Absorb, Be Displaced, Converge" ], "definition": "AI responsibilities can be absorbed by an incumbent role, displace its remit, or converge with another role; a new seat is useful only when the ownership and authority gaps are resolved.", "keyQuestion": "Is this new title going to be absorbed, displace the seat, or converge with it, and which of the four ownerships decides?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this new title going to be absorbed, displace the seat, or converge with it, and which of the four ownerships decides?", "evidence": "Map the four ownerships and actual authority before comparing title options.", "falsifier": "A new title without resolved authority or capability weakens a reorganization claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "No particular executive title is a universal solution.", "calibration": "No particular executive title is a universal solution.", "origin": "Reconciled from expansion pack entry 252; supplied source is not independent empirical validation.", "sourceIds": [ "pack:252" ], "usesConcept": [ "urn:business-engineer:concept:authority", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:seat" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:252" ], "instruments": [ "urn:business-engineer:instrument:responsibility-grid" ], "modes": [ "urn:business-engineer:mode:roles" ] }, { "@id": "urn:business-engineer:model:0256", "@type": "Model", "id": 256, "stableId": "BE-M0256", "name": "Deployment Decision Sequence", "aliases": [ "The CTO of Someone Else's Company (DEPLOY)" ], "definition": "Move an engagement through Discovery, Envelope, Proof, Landing, Outcome and Yield with dated decisions, evidence and accountable owners.", "keyQuestion": "Which letter of DEPLOY is this engagement on, what is its date, and what did the architect refuse in writing?", "form": "framework", "domains": [ "urn:business-engineer:domain:D09" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which letter of DEPLOY is this engagement on, what is its date, and what did the architect refuse in writing?", "evidence": "Track entry evidence, acceptance, constraints, refusal reasons and transition dates for each stage.", "falsifier": "Missing baselines or unsigned operating responsibility refute a claimed completed deployment.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The source's four discovery gates and seven-layer shape need explicit local definitions; model feasibility should be tested early.", "calibration": "The source's four discovery gates and seven-layer shape need explicit local definitions; model feasibility should be tested early.", "origin": "Reconciled from expansion pack entry 256; supplied source is not independent empirical validation.", "sourceIds": [ "pack:256" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:standard", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:256" ], "instruments": [ "urn:business-engineer:instrument:deploy" ], "modes": [ "urn:business-engineer:mode:deployment" ] }, { "@id": "urn:business-engineer:model:0257", "@type": "Model", "id": 257, "stableId": "BE-M0257", "name": "Intent-Based Monetization", "aliases": [ "Intent Is the Scarcest Thing on the Web" ], "definition": "A service can monetize information about a user's likely purchase or action when it improves matching, conversion or transaction value.", "keyQuestion": "Which of this business's margin assumptions rests on the copy being free, and does the copy still cost nothing?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Which of this business's margin assumptions rests on the copy being free, and does the copy still cost nothing?", "evidence": "Measure incremental conversion, auction or pricing economics, privacy constraints and substitution.", "falsifier": "Low incremental value or cheaper equivalent matching weakens the intent-rent thesis.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Intent is one scarce input among others; avoid universal profitability or zero-copy-cost claims.", "calibration": "Intent is one scarce input among others; avoid universal profitability or zero-copy-cost claims.", "origin": "Reconciled from expansion pack entry 260; supplied source is not independent empirical validation.", "sourceIds": [ "pack:260" ], "usesConcept": [ "urn:business-engineer:concept:constraint", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:value-attribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:260" ] }, { "@id": "urn:business-engineer:model:0258", "@type": "Model", "id": 258, "stableId": "BE-M0258", "name": "Transformation Direction", "aliases": [ "Web Squared (Outside-In and Inside-Out)" ], "definition": "Technology can change distribution, operations and the business model in different sequences depending on existing infrastructure and incentives.", "keyQuestion": "Is this transformation being attempted from the outside in, when the era runs from the inside out?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D03" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Is this transformation being attempted from the outside in, when the era runs from the inside out?", "evidence": "Date changes in workflows, economics and distribution, then compare plausible alternative sequences.", "falsifier": "Distribution-led AI change or operations-led web change refutes a universal era-specific sequence.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Outside-in and inside-out are contingent patterns, not historical laws or required branding.", "calibration": "Outside-in and inside-out are contingent patterns, not historical laws or required branding.", "origin": "Reconciled from expansion pack entry 261; supplied source is not independent empirical validation.", "sourceIds": [ "pack:261" ], "usesConcept": [ "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:distribution" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:261" ] }, { "@id": "urn:business-engineer:model:0259", "@type": "Model", "id": 259, "stableId": "BE-M0259", "name": "Dual-Surface Product Design", "aliases": [ "The Two Surfaces" ], "definition": "A product can expose a human interface and an agent specification or API over consistent business rules, permissions and state, evaluated against a shared outcome standard.", "keyQuestion": "Does this product have an agent surface, and is it graded by the same referee as the human one?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Does this product have an agent surface, and is it graded by the same referee as the human one?", "evidence": "Run representative tasks through both surfaces and compare accepted outcomes, authorization, state changes and exception handling.", "falsifier": "Divergent business rules or success on the screen with failure through the machine interface weakens the shared-product claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "The surfaces need not expose identical capabilities or workflows; define activation and retention in terms of actual accepted value where useful.", "calibration": "The surfaces need not expose identical capabilities or workflows; define activation and retention in terms of actual accepted value where useful.", "origin": "Reconciled from expansion pack entry 218; supplied source is not independent empirical validation.", "sourceIds": [ "pack:218" ], "usesConcept": [ "urn:business-engineer:concept:standard", "urn:business-engineer:concept:accepted-outcome", "urn:business-engineer:concept:permission", "urn:business-engineer:concept:process-specification", "urn:business-engineer:concept:human-surface", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:218" ] }, { "@id": "urn:business-engineer:model:0260", "@type": "Model", "id": 260, "stableId": "BE-M0260", "name": "Decision Residue Flywheel", "aliases": [ "The Exhaust Flywheel", "The Residue Loop" ], "definition": "Operational traces, adjudicated cases, evaluation results and configuration changes can improve subsequent work when permitted capture, curation and a tested learning process turn them into reusable assets.", "keyQuestion": "Where does this deployment's exhaust accumulate, and whose walls is it inside?", "form": "causal-hypothesis", "domains": [ "urn:business-engineer:domain:D06", "urn:business-engineer:domain:D08" ], "status": "Reconciled source framework", "validationStatus": "The ontology does not establish empirical validity.", "use_when": "Where does this deployment's exhaust accumulate, and whose walls is it inside?", "evidence": "Follow traces into curated cases, system changes, reuse and measured improvement across comparable decisions; identify who controls and benefits from each step.", "falsifier": "Growing records without better performance, lower rework or practical reuse weakens the flywheel claim.", "decision": "Use the observed result to accept, modify or reject the intervention or valuation implied by this mechanism.", "limits": "Provider training on customer data depends on contracts and settings. An open harness does not by itself guarantee retained rights, privacy or learning.", "calibration": "Provider training on customer data depends on contracts and settings. An open harness does not by itself guarantee retained rights, privacy or learning.", "origin": "Reconciled from expansion pack entry 194; supplied source is not independent empirical validation.", "applications": [ { "sourceId": "pack:219", "name": "Residue as a Second Output", "definition": "A successful work loop can deliver the immediate outcome and reusable evidence that improves later execution.", "evidence": "Measure artifact capture, curation, ownership, reuse and downstream performance separately.", "falsifier": "High capture without reuse or benefit weakens a compounding claim.", "limits": "The useful capture rate depends on task, privacy, consent and maintenance economics.", "mappingKind": "scopedVariant" } ], "sourceIds": [ "pack:194", "pack:219" ], "usesConcept": [ "urn:business-engineer:concept:residue", "urn:business-engineer:concept:ownership", "urn:business-engineer:concept:runtime", "urn:business-engineer:concept:adjudication" ], "sourceEntries": [ "urn:business-engineer:source-entry:pack:194", "urn:business-engineer:source-entry:pack:219" ] }, { "@id": "urn:business-engineer:domain:D01", "@type": "Domain", "id": "D01", "name": "Reasoning, evidence and learning", "definition": "How to frame, test, combine and revise an explanation." }, { "@id": "urn:business-engineer:domain:D02", "@type": "Domain", "id": "D02", "name": "Strategy, competition and value capture", "definition": "Where advantage comes from, how it persists and who captures value." }, { "@id": "urn:business-engineer:domain:D03", "@type": "Domain", "id": "D03", "name": "Markets, growth and distribution", "definition": "How an offer reaches demand and expands economically." }, { "@id": "urn:business-engineer:domain:D04", "@type": "Domain", "id": "D04", "name": "Technology, infrastructure and geopolitics", "definition": "How technological complements, constraints and political control shape systems." }, { "@id": "urn:business-engineer:domain:D05", "@type": "Domain", "id": "D05", "name": "Capital, financing and valuation", "definition": "How investment, cash flows, obligations and claims are funded and valued." }, { "@id": "urn:business-engineer:domain:D06", "@type": "Domain", "id": "D06", "name": "Intelligence systems and architecture", "definition": "How models, context, interfaces, tools and controls produce useful behavior." }, { "@id": "urn:business-engineer:domain:D07", "@type": "Domain", "id": "D07", "name": "Enterprise processes, ownership and procurement", "definition": "Who controls reusable operating assets and on what terms a buyer adopts them." }, { "@id": "urn:business-engineer:domain:D08", "@type": "Domain", "id": "D08", "name": "Deployment, product economics and outcomes", "definition": "How a capability becomes a reliable, accepted and economically useful outcome." }, { "@id": "urn:business-engineer:domain:D09", "@type": "Domain", "id": "D09", "name": "Organization, roles and expert work", "definition": "How authority, skills, coordination and learning shape firm performance." }, { "@id": "urn:business-engineer:concept:constraint", "@type": "Concept", "id": "constraint", "name": "Constraint", "definition": "A condition that limits a specified outcome under stated conditions." }, { "@id": "urn:business-engineer:concept:junction", "@type": "Concept", "id": "junction", "name": "Junction", "definition": "An interface where a consequential private or public rule, choice or dependency is coordinated or enforced." }, { "@id": "urn:business-engineer:concept:residue", "@type": "Concept", "id": "residue", "name": "Residue", "definition": "Reusable cases, rationale, corrections, standards or process knowledge produced alongside an immediate outcome." }, { "@id": "urn:business-engineer:concept:standard", "@type": "Concept", "id": "standard", "name": "Standard", "definition": "An explicit criterion for acceptable behavior or results, with a version and accountable authority." }, { "@id": "urn:business-engineer:concept:suite", "@type": "Concept", "id": "suite", "name": "Suite", "definition": "A versioned collection of evaluation cases, expected behavior, scoring rules and operating procedures." }, { "@id": "urn:business-engineer:concept:accepted-outcome", "@type": "Concept", "id": "accepted-outcome", "name": "Accepted Outcome", "definition": "An outcome that satisfies a stated acceptance standard for a defined unit and period." }, { "@id": "urn:business-engineer:concept:property-line", "@type": "Concept", "id": "property-line", "name": "Property Line", "definition": "The chosen boundary between owned or controlled durable assets and rented capabilities." }, { "@id": "urn:business-engineer:concept:absorption-boundary", "@type": "Concept", "id": "absorption-boundary", "name": "Absorption Boundary", "definition": "A scenario-dependent boundary between value exposed to substitution and value expected to persist." }, { "@id": "urn:business-engineer:concept:authority", "@type": "Concept", "id": "authority", "name": "Authority", "definition": "A recognized decision right to authorize, stop or change an action." }, { "@id": "urn:business-engineer:concept:permission", "@type": "Concept", "id": "permission", "name": "Permission", "definition": "A specific grant of access or action rights, subject to scope, conditions and revocation." }, { "@id": "urn:business-engineer:concept:ownership", "@type": "Concept", "id": "ownership", "name": "Ownership", "definition": "Specified legal or operational rights over an asset or control; the word alone does not establish title." }, { "@id": "urn:business-engineer:concept:portability", "@type": "Concept", "id": "portability", "name": "Portability", "definition": "The demonstrated ability to transfer a usable workload or artifact with retained meaning and acceptable cost." }, { "@id": "urn:business-engineer:concept:seat", "@type": "Concept", "id": "seat", "name": "Seat", "definition": "An actor's position in an economic flow; one actor can occupy several seats." }, { "@id": "urn:business-engineer:concept:clock", "@type": "Concept", "id": "clock", "name": "Clock", "definition": "A process-specific adjustment horizon; clocks can accelerate, stall or interact." }, { "@id": "urn:business-engineer:concept:process-specification", "@type": "Concept", "id": "process-specification", "name": "Process Specification", "definition": "A representation of intended workflow, decisions, state, roles and exception behavior." }, { "@id": "urn:business-engineer:concept:runtime", "@type": "Concept", "id": "runtime", "name": "Runtime", "definition": "The operating system components that execute a workflow and enforce relevant controls." }, { "@id": "urn:business-engineer:concept:obligation", "@type": "Concept", "id": "obligation", "name": "Obligation", "definition": "A contractual, legal or economically unavoidable exposure with timing, counterparties and conditions." }, { "@id": "urn:business-engineer:concept:flow", "@type": "Concept", "id": "flow", "name": "Flow", "definition": "An amount measured over a period, distinct from a stock measured at an instant." }, { "@id": "urn:business-engineer:concept:stock", "@type": "Concept", "id": "stock", "name": "Stock", "definition": "An amount measured at an instant; ratios to flows require explicit units and horizons." }, { "@id": "urn:business-engineer:concept:exposure", "@type": "Concept", "id": "exposure", "name": "Exposure", "definition": "The way an actor is affected by a specified event through assets, contracts or dependencies." }, { "@id": "urn:business-engineer:concept:institution", "@type": "Concept", "id": "institution", "name": "Institution", "definition": "A durable arrangement of rules, authority and enforcement that coordinates behavior." }, { "@id": "urn:business-engineer:concept:distribution", "@type": "Concept", "id": "distribution", "name": "Distribution", "definition": "The means by which an offer reaches demand and the parties controlling that access." }, { "@id": "urn:business-engineer:concept:rent", "@type": "Concept", "id": "rent", "name": "Rent", "definition": "An economic return associated with a scarce or protected position, whose durability requires explanation." }, { "@id": "urn:business-engineer:concept:claim", "@type": "Concept", "id": "claim", "name": "Claim", "definition": "A proposition to be tested, or a specified financial/legal entitlement; the intended sense must be stated." }, { "@id": "urn:business-engineer:concept:baseline", "@type": "Concept", "id": "baseline", "name": "Baseline", "definition": "A dated measurement before intervention or a defined counterfactual comparison." }, { "@id": "urn:business-engineer:concept:counter-model", "@type": "Concept", "id": "counter-model", "name": "Counter Model", "definition": "A competing explanation capable of changing the proposed decision." }, { "@id": "urn:business-engineer:concept:reversibility", "@type": "Concept", "id": "reversibility", "name": "Reversibility", "definition": "The practical ability and cost to undo an action and recover an acceptable prior state." }, { "@id": "urn:business-engineer:concept:operating-absorption", "@type": "Concept", "id": "operating-absorption", "name": "Operating Absorption", "definition": "The capacity of operating earnings to bear relevant operating charges, including depreciation." }, { "@id": "urn:business-engineer:concept:cash-absorption", "@type": "Concept", "id": "cash-absorption", "name": "Cash Absorption", "definition": "The capacity of cash generation and liquidity to cover investment, working capital and funding needs." }, { "@id": "urn:business-engineer:concept:circle", "@type": "Concept", "id": "circle", "name": "Circle", "definition": "Linked supplier, investor and customer financing flows that may correlate revenue with continued funding." }, { "@id": "urn:business-engineer:concept:counting-boundary", "@type": "Concept", "id": "counting-boundary", "name": "Counting Boundary", "definition": "The declared entities, transactions, period and accounting basis included in a measure." }, { "@id": "urn:business-engineer:concept:control-plane", "@type": "Concept", "id": "control-plane", "name": "Control Plane", "definition": "The function that authorizes, constrains, observes or interrupts execution." }, { "@id": "urn:business-engineer:concept:human-surface", "@type": "Concept", "id": "human-surface", "name": "Human Surface", "definition": "The interface and capabilities intended for human users." }, { "@id": "urn:business-engineer:concept:agent-surface", "@type": "Concept", "id": "agent-surface", "name": "Agent Surface", "definition": "The interface and capabilities intended for authorized machine users." }, { "@id": "urn:business-engineer:concept:substrate", "@type": "Concept", "id": "substrate", "name": "Substrate", "definition": "The durable operational state, semantics and infrastructure on which workflows depend." }, { "@id": "urn:business-engineer:concept:autonomy-envelope", "@type": "Concept", "id": "autonomy-envelope", "name": "Autonomy Envelope", "definition": "The scope within which a system may act without additional approval, with explicit limits and escalation." }, { "@id": "urn:business-engineer:concept:independent-evaluation", "@type": "Concept", "id": "independent-evaluation", "name": "Independent Evaluation", "definition": "Assessment with enough separation from delivery incentives and optimization to surface consequential failures." }, { "@id": "urn:business-engineer:concept:adjudication", "@type": "Concept", "id": "adjudication", "name": "Adjudication", "definition": "A responsible decision about an ambiguous result, exception or acceptance dispute." }, { "@id": "urn:business-engineer:concept:paved-road", "@type": "Concept", "id": "paved-road", "name": "Paved Road", "definition": "A supported route for building and operating work with known standards, infrastructure and responsibilities." }, { "@id": "urn:business-engineer:concept:drift", "@type": "Concept", "id": "drift", "name": "Drift", "definition": "A change in inputs, behavior, controls or outcomes relative to a monitored baseline or standard." }, { "@id": "urn:business-engineer:concept:residual-value", "@type": "Concept", "id": "residual-value", "name": "Residual Value", "definition": "Value expected to persist after an explicit decay or substitution scenario, distinct from an unexplained valuation remainder." }, { "@id": "urn:business-engineer:concept:value-attribution", "@type": "Concept", "id": "value-attribution", "name": "Value Attribution", "definition": "Evidence that an intervention caused an observed economic or operational change." }, { "@id": "urn:business-engineer:concept:coordination-capital", "@type": "Concept", "id": "coordination-capital", "name": "Coordination Capital", "definition": "Reusable shared standards, context and working relationships that lower the cost of coherent action." }, { "@id": "urn:business-engineer:concept:machine-buyer-preference", "@type": "Concept", "id": "machine-buyer-preference", "name": "Machine Buyer Preference", "definition": "A demonstrated tendency for authorized purchasing agents to choose an offer under relevant tasks and conditions." }, { "@id": "urn:business-engineer:instrument:capital-print", "@type": "Instrument", "id": "capital-print", "name": "Capital-Cycle Print", "definition": "Resolve one falsifiable question about a company or node in a buildout.", "inputs": [ "Reported results and footnotes", "Seat, layer, horizon and prior prediction" ], "steps": [ "Name the economic seat and state the question, frame and provisional verdict.", "Reconcile positive and negative non-operating effects without erasing economic costs.", "Run operating and cash absorption; run a capital-return test when required.", "Explain what this observation resolves about the wider map.", "Use price behavior as a late lens when useful, then state the verdict and next falsifier." ], "producesArtifact": [ "urn:business-engineer:artifact-type:capital-bridge", "urn:business-engineer:artifact-type:claim-ledger" ], "operationalizes": [ "urn:business-engineer:model:0182", "urn:business-engineer:model:0111", "urn:business-engineer:model:0115", "urn:business-engineer:model:0116", "urn:business-engineer:model:0132" ], "limits": "A market-price move is not a verdict. A single print does not establish long-run capital returns.", "origin": "Base A; pack patch list", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:incidence", "@type": "Instrument", "id": "incidence", "name": "Incidence and Seat Map", "definition": "Trace who initially pays and who ultimately bears a bill.", "inputs": [ "Actors, transactions, contracts and alternatives" ], "steps": [ "Assign one or more of the ten seats by exposure.", "Trace shared-input, discovery, financing and transaction channels.", "Distinguish immediate payer from economic incidence.", "Test blocked transmission and alternative beneficiaries." ], "producesArtifact": [ "urn:business-engineer:artifact-type:seat-map" ], "operationalizes": [ "urn:business-engineer:model:0182", "urn:business-engineer:model:0127", "urn:business-engineer:model:0140" ], "limits": "Seats are overlapping analytical positions. A renter is not automatically a causal control group.", "origin": "Base B; pack 154, 166", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:financing", "@type": "Instrument", "id": "financing", "name": "Financing Acid Test", "definition": "Assess funding visibility, self-funding capacity and exposure to credit and refinancing.", "inputs": [ "On- and off-balance-sheet obligations", "Cash flow, funding terms, counterparties and maturities" ], "steps": [ "Reconcile capitalized assets, leases, signed-not-commenced leases, non-cancelable commitments, contingent guarantees, non-consolidated vehicle debt and relevant third-party capex exposure.", "Show six gauges separately: off-book share, marginal financing change, external dependence, obligation coverage, counterparty credit and refinancing capacity.", "Supplement with integrator trade-credit float and supplier-funded customer exposure.", "Stress rates, demand, collateral, timing and counterparty failure; document recourse and risk transfer.", "Compare with a consistent historical baseline; publish raw dimensions and limitations." ], "producesArtifact": [ "urn:business-engineer:artifact-type:financing-board" ], "operationalizes": [ "urn:business-engineer:model:0114", "urn:business-engineer:model:0119", "urn:business-engineer:model:0120", "urn:business-engineer:model:0121", "urn:business-engineer:model:0122", "urn:business-engineer:model:0190", "urn:business-engineer:model:0194" ], "limits": "No calibrated universal SOUND-to-PRE-BREAK bands are supplied. Do not average hard failures away or call accounting non-consolidation risk transfer. Distinct-unit gauges cannot share an uncalibrated numeric rail.", "origin": "Base C; pack patches and 169–170", "formulas": [ "Off-book share = specified non-duplicated off-book exposure / matching total exposure. Show unweighted amounts before any justified risk weights.", "Coverage horizon ratio = matching-horizon obligations / cash available over that horizon; define taxes, reinvestment and financing consistently.", "Take-out coverage = credible refinancing capacity / refinancing need over the same maturity window. A stock/annual-flow ratio can be valid with units of years." ], "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:reconciliation", "@type": "Instrument", "id": "reconciliation", "name": "Operating, Capital and Funding Reconciliation", "definition": "Answer three different questions about operating charges, investment returns and the ability to pay.", "inputs": [ "Revenue, operating costs, depreciation and cash flow", "Investment, life, utilization, working capital, tax, salvage and funding schedules" ], "steps": [ "Reconcile operating earnings including relevant depreciation.", "Model discounted project cash flows and sensitivities.", "Reconcile liquidity and contractual funding requirements by period.", "Separate final-demand counting from gross value-chain transactions; reconcile whole-build capital to the actual revenue boundary.", "Treat agreement among external estimates as shared-vintage evidence unless inputs and methods are demonstrably independent." ], "producesArtifact": [ "urn:business-engineer:artifact-type:capital-bridge" ], "operationalizes": [ "urn:business-engineer:model:0111", "urn:business-engineer:model:0112", "urn:business-engineer:model:0115", "urn:business-engineer:model:0120", "urn:business-engineer:model:0229" ], "limits": "Capex/revenue is a capital-intensity ratio, not a return test. Asset life and timing matter. The level-annuity formula is a simplifying scenario.", "origin": "Base D; pack patch list", "formulas": [ "Level year-end annual cash contribution A = K*r/(1-(1+r)^(-n)) for r>0; A=K/n for r=0, with no salvage.", "If additional fixed annual cash cost F and cash-contribution margin m>0 apply, required revenue = (A+F)/m.", "Assumed revenue tripling over three years implies CAGR = 3^(1/3)-1 = 44.224957%; capex/depreciation alone does not imply tripling.", "Two counting repairs: compare whole-build capital with cash flows reconciled from final demand through the stack, or match each node capital base with its own compatible cash flows." ], "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:capture", "@type": "Instrument", "id": "capture", "name": "Enterprise Capture Test", "definition": "Determine what rights, useful artifacts and operating alternatives remain after an engagement.", "inputs": [ "Workload, artifact inventory, rights and export evidence", "Alternative runtime and migration estimates" ], "steps": [ "Assess control, capability, choice, cost and reusable knowledge separately.", "Inspect rights, export completeness, semantic integrity and alternative execution.", "Perform a representative sample exit.", "Classify each artifact as KEPT, PARTIAL or CAPTURED by operational burden and report the priced exit." ], "producesArtifact": [ "urn:business-engineer:artifact-type:priced-exit" ], "operationalizes": [ "urn:business-engineer:model:0135", "urn:business-engineer:model:0136", "urn:business-engineer:model:0148", "urn:business-engineer:model:0241" ], "limits": "Grades describe exit burden, not legal title. No validated capture-level or weighted-score calibration is supplied. Do not infer full independence from one open component.", "origin": "Base E; pack 192, 234, 237", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:season-map", "@type": "Instrument", "id": "season-map", "name": "Layered-Map Season Method", "definition": "Accumulate observations into a coherent cycle analysis.", "inputs": [ "Layer map, exposure map and prior claims" ], "steps": [ "Define the relevant clocks and one named question per node.", "Record observations and compare predictions across the season.", "Attach new evidence to existing mechanisms before inventing new models.", "Synthesize the capstone from tested relationships and unresolved alternatives." ], "producesArtifact": [ "urn:business-engineer:artifact-type:season-map", "urn:business-engineer:artifact-type:claim-ledger" ], "operationalizes": [ "urn:business-engineer:model:0123", "urn:business-engineer:model:0130", "urn:business-engineer:model:0131", "urn:business-engineer:model:0132", "urn:business-engineer:model:0133", "urn:business-engineer:model:0163" ], "limits": "Value-chain topology does not determine credit-contagion direction. Clock speeds are empirical.", "origin": "Base F; pack fifth-clock patch", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:valuation", "@type": "Instrument", "id": "valuation", "name": "Valuation Toolbox", "definition": "Audit the assumptions that connect reported measures to an estimate of operating and equity value.", "inputs": [ "Current accounts and disclosures", "Demand, cost, durability, funding and comparable assumptions" ], "steps": [ "Write a credible hostile case using the same boundary and date.", "1. What are you counting? Reconcile revenue tier, gross/net, payer and period.", "2. What does it cost to produce? Measure cost per accepted outcome and model the tail.", "3. What compounds? Verify reusable residue, standards, semantics and customer assets.", "4. What is owned or rented? Price rights, control and exit.", "5. What is perishable? Model substitution and retained value.", "6. Whose money? Trace payer classes, both earnings engines and financing circles.", "7. What capital and claims? Apply operating, return and funding tests and the EV bridge.", "8. What kills the value? Specify triggers, recovery and correlated failure cases.", "9. Use layer-consistent multiples as a cross-check on economically supported cash flows and explain the reconciliation gap." ], "producesArtifact": [ "urn:business-engineer:artifact-type:valuation-bridge" ], "operationalizes": [ "urn:business-engineer:model:0228", "urn:business-engineer:model:0229", "urn:business-engineer:model:0157", "urn:business-engineer:model:0230", "urn:business-engineer:model:0231", "urn:business-engineer:model:0232", "urn:business-engineer:model:0095", "urn:business-engineer:model:0162", "urn:business-engineer:model:0186" ], "limits": "Valuation is scenario-based analysis, not a transaction recommendation. V0–V5 thresholds are not specified or calibrated. Do not impose arbitrary counted-revenue discounts or a universal terminal-value haircut.", "origin": "Pack I; models 220–228", "formulas": [ "Operating EV bridge: equity value + debt and other included financing claims + preferred claims + noncontrolling interests - relevant cash/non-operating assets, with consistent scope.", "List contingent and debt-like exposures separately; include each cash-flow obligation once, in cash flows or the claim bridge as appropriate.", "Scenario value = sum(probability × consistent scenario value) only when the scenario set, dependence and probability basis are explicit." ], "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:verified", "@type": "Instrument", "id": "verified", "name": "VERIFIED Buyer Qualification", "definition": "Produce an evidence-backed qualification and negotiated operating boundary.", "inputs": [ "Buyer requirements, vendor terms, representative cases and operating constraints" ], "steps": [ "Run the evaluation-provenance screen first.", "V1 — Verification owned: buyer owns acceptance criteria and the evaluation evidence.", "E2 — Economics read: assess vendor margins, incentives, support capacity and pricing sustainability.", "R3 — Rights scheduled: contract for needed rights to data, semantics, standards and exports.", "I4 — Incentives separated: disclose conflicts and separate championing from acceptance authority.", "F5 — Feasibility on the buyer floor: test representative data, systems, permissions and operating conditions.", "I6 — Independence priced: estimate engineer effort, elapsed time, dual running and egress; rehearse a proportionate exit.", "E7 — Exposure governed: review behavioral changes alongside security, legal and operational requirements.", "D8 — Drift instrumented: assign monitoring, release checks, response authority and review cadence.", "Phase the work: V1/E2/I4 before contact where feasible; F5/R3/E7 during proof; I6/D8 before signature; review on material change and a risk-based cadence.", "Classify each gap as a hard gate, remediable condition, commercial exposure or unresolved uncertainty; record its disposition." ], "producesArtifact": [ "urn:business-engineer:artifact-type:verified-board", "urn:business-engineer:artifact-type:priced-exit" ], "operationalizes": [ "urn:business-engineer:model:0235", "urn:business-engineer:model:0236", "urn:business-engineer:model:0136", "urn:business-engineer:model:0149", "urn:business-engineer:model:0157" ], "limits": "The repeated E and I letters require the unique keys shown here. Mandatory authority, legal and safety gates cannot be exchanged for a price concession. Pure outcome pricing is not a required destination.", "origin": "Pack J; models 229–238", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:deploy", "@type": "Instrument", "id": "deploy", "name": "DEPLOY Decision Sequence", "definition": "Turn a customer problem into a dated production decision and reusable learning.", "inputs": [ "Customer outcome, sponsor, workflow, system access and constraints" ], "steps": [ "Discovery: specify outcome and baseline, validate gates, document refusals and alternatives.", "Envelope: define process, data path, architecture, authority, buy/build/rent and operating responsibility; test model feasibility early.", "Proof: use a bounded contract with acceptance cases, guardrails, approval and rollback.", "Landing: complete operational, security and buyer reviews and hand over named responsibilities.", "Outcome: compare accepted results with baseline, total cost and an attributable finance-relevant benefit.", "Yield: capture reference architecture, product requirements, useful residue and refusal lessons.", "Date every stage and decision; adapt the same evidence for engineers, technology/risk leaders and business leaders." ], "producesArtifact": [ "urn:business-engineer:artifact-type:deploy-board", "urn:business-engineer:artifact-type:charter", "urn:business-engineer:artifact-type:gauge-page", "urn:business-engineer:artifact-type:refusal-log", "urn:business-engineer:artifact-type:reference-architecture" ], "operationalizes": [ "urn:business-engineer:model:0256", "urn:business-engineer:model:0153", "urn:business-engineer:model:0145", "urn:business-engineer:model:0158", "urn:business-engineer:model:0223", "urn:business-engineer:model:0224" ], "limits": "The pack names but does not define four discovery gates or a seven-layer envelope. The proposed local defaults below are design choices, not recovered source facts. A portfolio view is useful only when multiple engagements exist.", "origin": "Pack K; model 256", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:climb", "@type": "Instrument", "id": "climb", "name": "Organization Climb", "definition": "Test whether task gains propagate into organizational capability and retained economic value.", "inputs": [ "Comparable task, workflow, firm and market measurements", "Authority map, loop inventory and supported paths" ], "steps": [ "Diagnose relative advantage before claiming transformation.", "Follow gains through task, workflow, firm and market scales and identify the blocked transmission.", "Map local discovery, common infrastructure and accountability.", "Measure six gauges: loop share, adjudication ratio, residue capture, paved-road coverage, conversion time and aim traceability.", "Use quality and authority gates before changing spans or staffing; include shadow work and contractors in the relevant denominators.", "Rebuild apprenticeship where routine practice has disappeared; test competence through cases and failures." ], "producesArtifact": [ "urn:business-engineer:artifact-type:gauge-page", "urn:business-engineer:artifact-type:responsibility-grid", "urn:business-engineer:artifact-type:claim-ledger" ], "operationalizes": [ "urn:business-engineer:model:0243", "urn:business-engineer:model:0244", "urn:business-engineer:model:0245", "urn:business-engineer:model:0248", "urn:business-engineer:model:0250", "urn:business-engineer:model:0254" ], "limits": "The source does not define its six stages or O0–O5/W0–W5 thresholds. Report evidence by dimension until a local rubric is agreed. Targets of 90% residue and under 90 days are unvalidated design targets. Headcount and naked revenue/employee are insufficient.", "origin": "Pack L; models 239–255. Gauge names are sourced; the following operational formulas are proposed local definitions and must be accepted before use.", "formulas": [ "Loop share = accepted work units passing through defined governed loops / eligible work units, same scope and date.", "Adjudication ratio = units requiring human judgment / evaluated units; distinguish sampling review from exceptions.", "Residue capture = eligible useful decisions with usable permitted artifacts / eligible useful decisions; pair with reuse and benefit.", "Paved-road coverage = relevant work on supported paths / total relevant work, including an explicit shadow estimate.", "Conversion time = elapsed time from a declared start event to independently accepted operating use.", "Aim traceability = active loops linked to an explicit business aim, owner and outcome measure / active loops." ], "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:junction", "@type": "Instrument", "id": "junction", "name": "Junction Read", "definition": "Explain where a technology system becomes a question of political control and dependency.", "inputs": [ "Physical and industrial system map", "Standards, permissions, budgets, institutions and alternatives" ], "steps": [ "Test siting, standardization and concentrated dependencies.", "Identify the junction and the complementary technologies supporting it.", "Locate revocable permissions and responsible institutions.", "Run physical, financial, efficiency, adoption and political clocks.", "Name the dependency being removed and the one being introduced.", "Assess lawful substitution and control effectiveness at the relevant policy boundary.", "Explain strategic and domestic distributional consequences with historical evidence.", "State alternative explanations and lag hypotheses without imposing a three-generation timetable." ], "producesArtifact": [ "urn:business-engineer:artifact-type:seat-map", "urn:business-engineer:artifact-type:season-map", "urn:business-engineer:artifact-type:claim-ledger" ], "operationalizes": [ "urn:business-engineer:model:0171", "urn:business-engineer:model:0172", "urn:business-engineer:model:0173", "urn:business-engineer:model:0174", "urn:business-engineer:model:0170", "urn:business-engineer:model:0137", "urn:business-engineer:model:0138", "urn:business-engineer:model:0139", "urn:business-engineer:model:0141" ], "limits": "Use a cross-section of physical base, techno-industrial system and power; capital, institutions and permissions cross these layers. Verify changing legal and geopolitical facts. Avoid operational evasion or targeting instructions.", "origin": "Pack M", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:suite", "@type": "Instrument", "id": "suite", "name": "Independent Evaluation Suite", "definition": "Operationalize an acceptance standard with tests that can fail.", "inputs": [ "Representative cases, standard, risk tier and evaluators" ], "steps": [ "Separate training/tuning cases, held-out cases, fresh cases and live monitoring.", "Version cases, expected behavior, scoring, ownership and access.", "Check contamination, coverage and inter-rater disagreement.", "Evaluate releases and investigate divergences from real outcomes." ], "producesArtifact": [ "urn:business-engineer:artifact-type:evaluation-suite", "urn:business-engineer:artifact-type:drift-log" ], "operationalizes": [ "urn:business-engineer:model:0222", "urn:business-engineer:model:0221", "urn:business-engineer:model:0223", "urn:business-engineer:model:0149" ], "limits": "Frozen does not mean timeless or sufficient. Independence and refresh must fit the risk.", "origin": "Pack Thread; 208–210", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:charter", "@type": "Instrument", "id": "charter", "name": "Loop Charter", "definition": "Make outcome, behavior and authority reviewable before operation.", "inputs": [ "Outcome, standard, process, parties and risk" ], "steps": [ "Record outcome and acceptance standard.", "Specify thresholds and their basis, human and agent surfaces, data and action boundaries.", "Record autonomy tier, named owner, stop authority, escalation and review trigger." ], "producesArtifact": [ "urn:business-engineer:artifact-type:charter" ], "operationalizes": [ "urn:business-engineer:model:0224", "urn:business-engineer:model:0160", "urn:business-engineer:model:0147", "urn:business-engineer:model:0254" ], "limits": "The charter is an artifact-backed agreement; it does not itself grant authority or validate thresholds.", "origin": "Pack Thread", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:gauge-page", "@type": "Instrument", "id": "gauge-page", "name": "Outcome Gauge Page", "definition": "Connect operation to accepted value and a renewal or change decision.", "inputs": [ "Dated baseline, outcome evidence, cost and comparison design" ], "steps": [ "Show accepted quality, total cost and throughput with consistent units.", "Explain attribution, uncertainty, exceptions and retained learning.", "Compare against contract or charter criteria and record the continue/change/stop decision." ], "producesArtifact": [ "urn:business-engineer:artifact-type:gauge-page" ], "operationalizes": [ "urn:business-engineer:model:0157", "urn:business-engineer:model:0158", "urn:business-engineer:model:0244" ], "limits": "A before/after comparison may be confounded; show the strength of the causal design.", "origin": "Pack Thread; K and L", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:priced-exit", "@type": "Instrument", "id": "priced-exit", "name": "Priced Exit Rehearsal", "definition": "Test whether portability is practicable within the required time and cost.", "inputs": [ "Artifact inventory, licenses, export, alternative runtime and staff" ], "steps": [ "Move a representative workload through a permitted alternative path.", "Record semantic losses, retraining, missing controls, integration changes and dual-running cost.", "Report effort, elapsed time, cash, risks and owner for the remaining transition." ], "producesArtifact": [ "urn:business-engineer:artifact-type:priced-exit" ], "operationalizes": [ "urn:business-engineer:model:0148", "urn:business-engineer:model:0136", "urn:business-engineer:model:0241" ], "limits": "A six-week target or an annual cadence is a configurable choice. Test rights as well as technical export.", "origin": "Pack Thread; VERIFIED; earlier expansion", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:drift", "@type": "Instrument", "id": "drift", "name": "Drift Check", "definition": "Detect when releases or changing conditions invalidate acceptance evidence.", "inputs": [ "Versioned suite, live outcomes, incidents and change log" ], "steps": [ "Re-score relevant cases on each material release or process change.", "Inspect input, behavior, permission and outcome drift.", "Record severity, rollback or mitigation, owner and revised baseline." ], "producesArtifact": [ "urn:business-engineer:artifact-type:drift-log" ], "operationalizes": [ "urn:business-engineer:model:0164", "urn:business-engineer:model:0222", "urn:business-engineer:model:0156" ], "limits": "Scores alone do not establish safety; include live exceptions and new failure modes.", "origin": "Pack Thread", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:instrument:responsibility-grid", "@type": "Instrument", "id": "responsibility-grid", "name": "Responsibility Grid", "definition": "Make lifecycle responsibility and handoff ownership explicit.", "inputs": [ "Lifecycle, active loops, people and authority" ], "steps": [ "Use the five-stage core: specify, prepare, build, deploy, evaluate.", "Use the five functions: business owner, domain owner, builder, evaluation owner, adoption owner.", "Assign one accountable owner to each active work package or handoff, contributors as needed, and explicit N/A cells.", "Map specialist contributions to functions without confusing job titles with decision rights.", "Use the proposed eleven-stage refinement only when it helps distinguish integration, approval and operations." ], "producesArtifact": [ "urn:business-engineer:artifact-type:responsibility-grid" ], "operationalizes": [ "urn:business-engineer:model:0153", "urn:business-engineer:model:0254", "urn:business-engineer:model:0149", "urn:business-engineer:model:0255" ], "limits": "An empty cell is only a defect when the responsibility is required. The source-backed core is 5×5; the 11-stage extension is a stated proposal. Independent acceptance should be proportionate to risk.", "origin": "Pack L and 253; earlier deployment bench", "requiredRecord": "Owner, as-of date, unit, source, threshold basis, result, uncertainty and decision." }, { "@id": "urn:business-engineer:mode:strategic", "@type": "OperationalMode", "id": "strategic", "name": "Strategic Analysis", "trigger": "A company, business model, competitive or industry question.", "definition": "Frame the decision, choose mechanisms and a counter-model, then derive action and evidence.", "usesInstrument": [ "urn:business-engineer:instrument:charter", "urn:business-engineer:instrument:gauge-page" ], "usesModel": [ "urn:business-engineer:model:0001", "urn:business-engineer:model:0015", "urn:business-engineer:model:0016", "urn:business-engineer:model:0038", "urn:business-engineer:model:0066", "urn:business-engineer:model:0162" ] }, { "@id": "urn:business-engineer:mode:visual", "@type": "OperationalMode", "id": "visual", "name": "Visual Intelligence", "trigger": "A diagram, infographic, dashboard or visual synthesis.", "definition": "Complete the reasoning, choose the representation and apply the appropriate visual register.", "usesModel": [ "urn:business-engineer:model:0004", "urn:business-engineer:model:0005", "urn:business-engineer:model:0009" ] }, { "@id": "urn:business-engineer:mode:lookup", "@type": "OperationalMode", "id": "lookup", "name": "Framework Lookup", "trigger": "Find, compare or apply a mental model.", "definition": "Resolve the identifier namespace, select by mechanism and read boundaries.", "usesModel": [ "urn:business-engineer:model:0003", "urn:business-engineer:model:0008", "urn:business-engineer:model:0162" ] }, { "@id": "urn:business-engineer:mode:print", "@type": "OperationalMode", "id": "print", "name": "Capital-Cycle Print", "trigger": "Earnings, quarterly results or a buildout node.", "definition": "Name the seat before selecting its tests.", "usesInstrument": [ "urn:business-engineer:instrument:capital-print", "urn:business-engineer:instrument:incidence", "urn:business-engineer:instrument:financing", "urn:business-engineer:instrument:reconciliation" ], "usesModel": [ "urn:business-engineer:model:0182", "urn:business-engineer:model:0111", "urn:business-engineer:model:0115", "urn:business-engineer:model:0116" ] }, { "@id": "urn:business-engineer:mode:capture", "@type": "OperationalMode", "id": "capture", "name": "Buyer-Side Capture Audit", "trigger": "Lock-in, dependency, ownership or exit cost.", "definition": "Inspect artifacts and rights, then exercise and price an exit.", "usesInstrument": [ "urn:business-engineer:instrument:capture", "urn:business-engineer:instrument:priced-exit" ], "usesModel": [ "urn:business-engineer:model:0135", "urn:business-engineer:model:0136", "urn:business-engineer:model:0148", "urn:business-engineer:model:0241" ] }, { "@id": "urn:business-engineer:mode:season", "@type": "OperationalMode", "id": "season", "name": "Season Map", "trigger": "Multi-print synthesis, capital-cycle tracker or capstone.", "definition": "Accumulate evidence by node and clock.", "usesInstrument": [ "urn:business-engineer:instrument:season-map", "urn:business-engineer:instrument:incidence" ], "usesModel": [ "urn:business-engineer:model:0123", "urn:business-engineer:model:0130", "urn:business-engineer:model:0131", "urn:business-engineer:model:0132" ] }, { "@id": "urn:business-engineer:mode:valuation", "@type": "OperationalMode", "id": "valuation", "name": "Valuation", "trigger": "Worth, valuation, multiples, run-rates, residual value or priced expectations.", "definition": "Use nine questions, a hostile case and a reconciled claim bridge.", "usesInstrument": [ "urn:business-engineer:instrument:valuation", "urn:business-engineer:instrument:reconciliation", "urn:business-engineer:instrument:financing" ], "usesModel": [ "urn:business-engineer:model:0228", "urn:business-engineer:model:0229", "urn:business-engineer:model:0230", "urn:business-engineer:model:0231", "urn:business-engineer:model:0232", "urn:business-engineer:model:0095" ] }, { "@id": "urn:business-engineer:mode:buyer", "@type": "OperationalMode", "id": "buyer", "name": "Buyer Qualification", "trigger": "Vendor, RFP, pilot, procurement or renewal.", "definition": "Check evaluation provenance and complete the eight-key board.", "usesInstrument": [ "urn:business-engineer:instrument:verified", "urn:business-engineer:instrument:suite", "urn:business-engineer:instrument:priced-exit" ], "usesModel": [ "urn:business-engineer:model:0234", "urn:business-engineer:model:0235", "urn:business-engineer:model:0236", "urn:business-engineer:model:0136" ] }, { "@id": "urn:business-engineer:mode:deployment", "@type": "OperationalMode", "id": "deployment", "name": "Deployment Decision", "trigger": "Rollout, proof of value, implementation or production handover.", "definition": "Advance DEPLOY through dated evidence-backed decisions.", "usesInstrument": [ "urn:business-engineer:instrument:deploy", "urn:business-engineer:instrument:charter", "urn:business-engineer:instrument:suite", "urn:business-engineer:instrument:gauge-page" ], "usesModel": [ "urn:business-engineer:model:0256", "urn:business-engineer:model:0153", "urn:business-engineer:model:0157", "urn:business-engineer:model:0158" ] }, { "@id": "urn:business-engineer:mode:organization", "@type": "OperationalMode", "id": "organization", "name": "Organization Climb", "trigger": "Task gains, AI transformation, span, productivity or governance.", "definition": "Trace gains across scales and measure the six gauges.", "usesInstrument": [ "urn:business-engineer:instrument:climb", "urn:business-engineer:instrument:responsibility-grid", "urn:business-engineer:instrument:gauge-page" ], "usesModel": [ "urn:business-engineer:model:0243", "urn:business-engineer:model:0244", "urn:business-engineer:model:0245", "urn:business-engineer:model:0248", "urn:business-engineer:model:0250" ] }, { "@id": "urn:business-engineer:mode:roles", "@type": "OperationalMode", "id": "roles", "name": "Roles and Grid", "trigger": "Hiring, team design, executive seats or responsibility.", "definition": "Resolve four ownerships, five functions and required lifecycle handoffs.", "usesInstrument": [ "urn:business-engineer:instrument:responsibility-grid", "urn:business-engineer:instrument:charter" ], "usesModel": [ "urn:business-engineer:model:0153", "urn:business-engineer:model:0254", "urn:business-engineer:model:0255", "urn:business-engineer:model:0149" ] }, { "@id": "urn:business-engineer:mode:geopolitics", "@type": "OperationalMode", "id": "geopolitics", "name": "Junction and Geopolitics", "trigger": "Political control, infrastructure dependencies, export rules or sovereignty.", "definition": "Test junctions, permissions, dependency migration and five clocks.", "usesInstrument": [ "urn:business-engineer:instrument:junction", "urn:business-engineer:instrument:season-map" ], "usesModel": [ "urn:business-engineer:model:0171", "urn:business-engineer:model:0172", "urn:business-engineer:model:0173", "urn:business-engineer:model:0170", "urn:business-engineer:model:0131" ] }, { "@id": "urn:business-engineer:artifact-type:claim-ledger", "@type": "ArtifactType", "id": "claim-ledger", "name": "Claim and prediction ledger", "definition": "Claim, evidence, date, assumption, alternative, prediction, trigger, owner and revised decision." }, { "@id": "urn:business-engineer:artifact-type:seat-map", "@type": "ArtifactType", "id": "seat-map", "name": "Seat and exposure map", "definition": "Actor, role, layer, payer, obligation, exposure and horizon." }, { "@id": "urn:business-engineer:artifact-type:capital-bridge", "@type": "ArtifactType", "id": "capital-bridge", "name": "Capital and cash-flow reconciliation", "definition": "Operating, return and funding tests with compatible periods and units." }, { "@id": "urn:business-engineer:artifact-type:financing-board", "@type": "ArtifactType", "id": "financing-board", "name": "Financing board", "definition": "Separate visibility, funding, coverage, credit and refinancing dimensions with raw data." }, { "@id": "urn:business-engineer:artifact-type:valuation-bridge", "@type": "ArtifactType", "id": "valuation-bridge", "name": "Valuation bridge", "definition": "Reported measures to counted measures, cash flows, claims, scenarios and implied value." }, { "@id": "urn:business-engineer:artifact-type:verified-board", "@type": "ArtifactType", "id": "verified-board", "name": "VERIFIED board", "definition": "Eight uniquely keyed rows with owners, artifacts, dates, status and risk dispositions." }, { "@id": "urn:business-engineer:artifact-type:deploy-board", "@type": "ArtifactType", "id": "deploy-board", "name": "DEPLOY board", "definition": "Six dated stages, evidence, decisions, owners, refusal reasons and next gates." }, { "@id": "urn:business-engineer:artifact-type:evaluation-suite", "@type": "ArtifactType", "id": "evaluation-suite", "name": "Evaluation suite", "definition": "Versioned cases, expected behavior, holdouts, scoring rules, ownership and refresh protocol." }, { "@id": "urn:business-engineer:artifact-type:charter", "@type": "ArtifactType", "id": "charter", "name": "Loop charter", "definition": "Outcome, standard, thresholds, surfaces, boundaries, autonomy tier, owner and escalation." }, { "@id": "urn:business-engineer:artifact-type:gauge-page", "@type": "ArtifactType", "id": "gauge-page", "name": "Gauge page", "definition": "Baseline, outcomes, quality, cost, attribution, uncertainties and renewal decision." }, { "@id": "urn:business-engineer:artifact-type:priced-exit", "@type": "ArtifactType", "id": "priced-exit", "name": "Priced exit table", "definition": "Artifacts, rights, exports, alternative runtime, migration effort, elapsed time and owner." }, { "@id": "urn:business-engineer:artifact-type:drift-log", "@type": "ArtifactType", "id": "drift-log", "name": "Drift log", "definition": "Release or change, affected cases, scores, incidents, disposition and accountable owner." }, { "@id": "urn:business-engineer:artifact-type:responsibility-grid", "@type": "ArtifactType", "id": "responsibility-grid", "name": "Responsibility grid", "definition": "Lifecycle by accountability function, with accountable person, contributors and handoff evidence." }, { "@id": "urn:business-engineer:artifact-type:season-map", "@type": "ArtifactType", "id": "season-map", "name": "Season map", "definition": "Layer and exposure maps, asynchronous clocks, per-node questions and accumulated evidence." }, { "@id": "urn:business-engineer:artifact-type:refusal-log", "@type": "ArtifactType", "id": "refusal-log", "name": "Refusal log", "definition": "Rejected request, violated constraint, evidence, alternative and decision owner." }, { "@id": "urn:business-engineer:artifact-type:reference-architecture", "@type": "ArtifactType", "id": "reference-architecture", "name": "Reference architecture", "definition": "Reusable workflow, interfaces, controls, evidence and documented local deviations." }, { "@id": "urn:business-engineer:artifact-type:editorial-plate", "@type": "ArtifactType", "id": "editorial-plate", "name": "Editorial mechanism plate", "definition": "A self-contained drawing of one mechanism with legible labels and evidence-consistent geometry." }, { "@id": "urn:business-engineer:role:builder", "@type": "Role", "id": "builder", "name": "Builder", "roleKind": "Economic seat", "definition": "Commits direct investment in the build.", "evidence": "Operating, capital-return and funding reconciliation.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:bystander", "@type": "Role", "id": "bystander", "name": "Bystander", "roleKind": "Economic seat", "definition": "Bears shared-input costs without building the relevant capacity.", "evidence": "Input pass-through, substitution and margin exposure.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:distributor", "@type": "Role", "id": "distributor", "name": "Distributor", "roleKind": "Economic seat", "definition": "Connects users to demand through a channel.", "evidence": "Discovery, referral, conversion and bargaining effects.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:renter-comparator", "@type": "Role", "id": "renter-comparator", "name": "Renter / comparator", "roleKind": "Economic seat", "definition": "Expenses or rents a capability rather than owning the build.", "evidence": "Contract obligations, access, exit and counterparty exposure; not automatically a control group.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:supplier", "@type": "Role", "id": "supplier", "name": "Supplier", "roleKind": "Economic seat", "definition": "Receives spending on the build and may finance customers.", "evidence": "Demand independence, customer credit and supplier-financing exposure.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:funder", "@type": "Role", "id": "funder", "name": "Funder", "roleKind": "Economic seat", "definition": "Supplies capital to the build.", "evidence": "Credit, collateral, covenants, tenor and refinancing.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:integrator", "@type": "Role", "id": "integrator", "name": "Integrator", "roleKind": "Economic seat", "definition": "Combines inputs and can fund the delivery-to-collection gap.", "evidence": "Working capital, trade credit, inventory and acceptance timing.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:value-capture-pole", "@type": "Role", "id": "value-capture-pole", "name": "Value-capture pole", "roleKind": "Economic seat", "definition": "Receives build-related value without necessarily financing its contracted capacity floor.", "evidence": "Durability, concentration and retained obligations.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:rail", "@type": "Role", "id": "rail", "name": "Transaction rail", "roleKind": "Economic seat", "definition": "Provides a transaction or coordination path on which the system relies.", "evidence": "Substitution, interoperability, permissions and transaction economics.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:taxed", "@type": "Role", "id": "taxed", "name": "Attention-exposed actor", "roleKind": "Economic seat", "definition": "Supplies attention or information that a changing interface can summarize or intermediate.", "evidence": "Substitution by task, retained demand and monetization rights.", "definedByModel": "urn:business-engineer:model:0182" }, { "@id": "urn:business-engineer:role:process-cartographer", "@type": "Role", "id": "process-cartographer", "name": "Process Cartographer", "roleKind": "Specialist contribution", "definition": "Makes workflows, semantics, handoffs and exceptions explicit.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:orchestration-architect", "@type": "Role", "id": "orchestration-architect", "name": "Orchestration Architect", "roleKind": "Specialist contribution", "definition": "Designs execution, integration, permission boundaries and resilience.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:value-engineer", "@type": "Role", "id": "value-engineer", "name": "Value Engineer", "roleKind": "Specialist contribution", "definition": "Defines baseline, acceptance economics and attributable outcomes.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:enterprise-partner", "@type": "Role", "id": "enterprise-partner", "name": "Enterprise Partner", "roleKind": "Specialist contribution", "definition": "Coordinates buyer authority, adoption and the commercial operating relationship.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:function-business-owner", "@type": "Role", "id": "function-business-owner", "name": "Business owner", "roleKind": "Accountability function", "definition": "Accountable for the business outcome and resources.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:function-domain-owner", "@type": "Role", "id": "function-domain-owner", "name": "Domain owner", "roleKind": "Accountability function", "definition": "Accountable for domain meaning and expert judgment.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:function-builder", "@type": "Role", "id": "function-builder", "name": "Builder", "roleKind": "Accountability function", "definition": "Accountable for implementation and operational delivery.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:function-evaluation-owner", "@type": "Role", "id": "function-evaluation-owner", "name": "Evaluation owner", "roleKind": "Accountability function", "definition": "Accountable for acceptance standards and independent assessment.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:role:function-adoption-owner", "@type": "Role", "id": "function-adoption-owner", "name": "Adoption owner", "roleKind": "Accountability function", "definition": "Accountable for uptake, training and workflow integration.", "definedByModel": "urn:business-engineer:model:0153" }, { "@id": "urn:business-engineer:clock:physical", "@type": "Clock", "id": "physical", "name": "Physical", "definition": "Construction, equipment life, capacity deployment and physical replacement.", "evidence": "Capacity dates, utilization, lead times and remaining service life.", "limits": "Set the horizon in the case. The clock label does not supply a fixed speed or guarantee support." }, { "@id": "urn:business-engineer:clock:financial", "@type": "Clock", "id": "financial", "name": "Financial", "definition": "Cash generation, commitments, debt maturity, refinancing and valuation adjustment.", "evidence": "Cash-flow periods, obligation schedules, covenants and funding terms.", "limits": "Set the horizon in the case. The clock label does not supply a fixed speed or guarantee support." }, { "@id": "urn:business-engineer:clock:efficiency", "@type": "Clock", "id": "efficiency", "name": "Efficiency", "definition": "Changes in cost or useful output per resource unit and their effect on installed assets.", "evidence": "Comparable workload cost, quality, throughput and vintage economics.", "limits": "Set the horizon in the case. The clock label does not supply a fixed speed or guarantee support." }, { "@id": "urn:business-engineer:clock:adoption", "@type": "Clock", "id": "adoption", "name": "Adoption", "definition": "The development of customer demand, workflow readiness and organizational uptake.", "evidence": "Cohorts, conversion, use, retention and accepted outcomes.", "limits": "Set the horizon in the case. The clock label does not supply a fixed speed or guarantee support." }, { "@id": "urn:business-engineer:clock:political", "@type": "Clock", "id": "political", "name": "Political", "definition": "Changes in policy objectives, permissions, fiscal support and state procurement.", "evidence": "Enacted authority, budgets, contracts, implementation and revocation dates.", "limits": "Set the horizon in the case. The clock label does not supply a fixed speed or guarantee support." }, { "@id": "urn:business-engineer:practice-rule:selection", "@type": "PracticeRule", "id": "selection", "name": "Select by decision and mechanism", "definition": "Name the decision, actor or economic seat, layer, unit and horizon. Select two or three complementary lenses for a complex case, including a credible counter-model; fewer are appropriate for a narrow question.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:epistemic", "@type": "PracticeRule", "id": "epistemic", "name": "Separate formulation from evidence", "definition": "Distinguish observed fact, user context, inference, proposal and historical illustration. A source paragraph is not current evidence; preserve attribution and verify changing claims.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:merge", "@type": "PracticeRule", "id": "merge", "name": "Canonicalize mechanisms, preserve source entries", "definition": "Keep canonical IDs stable. Merge equivalents, attach scoped variants and cases, and add a model only for a distinct question or mechanism with useful evidence and boundaries.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:gates", "@type": "PracticeRule", "id": "gates", "name": "Hard gates remain separate from preferences", "definition": "Do not average away missing required authority, unacceptable safety exposure or mandatory legal requirements. Price or mitigate only risks that can legitimately be traded.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:numbers", "@type": "PracticeRule", "id": "numbers", "name": "Use compatible units and defensible precision", "definition": "State period, population, boundary, units and uncertainty. Stock/flow ratios can be valid with dimensions. Exact arithmetic need not carry an invented range; uncertain estimates should show meaningful sensitivity.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:scores", "@type": "PracticeRule", "id": "scores", "name": "Do not invent grading calibration", "definition": "V0–V5, O0–O5, W0–W5, capture levels and financing bands lack complete calibrated thresholds. Report raw dimensions or an explicitly proposed local rubric; do not present an assigned grade as source-validated.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:targets", "@type": "PracticeRule", "id": "targets", "name": "Treat numeric targets as configurable", "definition": "90% residue capture, 90-day conversion or apprenticeship, six-week exit and fifty seed cases are source targets or illustrations, not universal empirical requirements.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:writing", "@type": "PracticeRule", "id": "writing", "name": "Write mechanisms in plain language", "definition": "Introduce the idea before its label. Favor connected sentences and load-bearing claims. Rough forty-word sentence and ten-to-twelve bold-claim budgets are editorial heuristics, not hard limits for every artifact.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:external", "@type": "PracticeRule", "id": "external", "name": "Deliver self-standing analysis", "definition": "For publishable analysis, omit drafting seams, label composite cases and make the why-now, limits and comparison questions clear. An ontology maintenance document may explicitly discuss source reconciliation.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:thread", "@type": "PracticeRule", "id": "thread", "name": "Use a shared instrument registry", "definition": "Shared registry of the twelve named Thread members: SUITE, CHARTER, GAUGE PAGE, TWO SURFACES, JUNCTION, RESIDUE, PROPERTY LINE, DRIFT CHECK, ABSORPTION LINE, COUNTING RULE, CIRCLE and SEAT. Link each use to its full definition; members have distinct types.", "status": "Reconciled application guidance", "threadMembers": [ "urn:business-engineer:instrument:suite", "urn:business-engineer:instrument:charter", "urn:business-engineer:instrument:gauge-page", "urn:business-engineer:instrument:drift", "urn:business-engineer:model:0259", "urn:business-engineer:concept:junction", "urn:business-engineer:concept:residue", "urn:business-engineer:concept:property-line", "urn:business-engineer:concept:absorption-boundary", "urn:business-engineer:concept:counting-boundary", "urn:business-engineer:concept:circle", "urn:business-engineer:concept:seat" ] }, { "@id": "urn:business-engineer:practice-rule:title-verbs", "@type": "PracticeRule", "id": "title-verbs", "name": "Use verdict verbs when they clarify a capital print", "definition": "Available verbs include Absorbed, Paid for, Overshot, Skipped, Reached, Escaped, Priced, Funded, Bought, Financed, Conceded, Collected and Swallowed. Season-wide uniqueness is optional style, not an analytical constraint.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:revenue", "@type": "PracticeRule", "id": "revenue", "name": "Keep accounting and analytical counting distinct", "definition": "Reported revenue, gross transactions and final-customer demand answer different questions. Trace financing circles without automatically declaring recognized revenue fictitious.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:accounting", "@type": "PracticeRule", "id": "accounting", "name": "Reconcile recognition and cash timing", "definition": "A receivable is an unconditional payment right; a contract asset depends on further conditions after performance; advance payment can create a contract liability. Backlog alone does not determine classification.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:regulatory", "@type": "PracticeRule", "id": "regulatory", "name": "Verify rules in the applicable scope", "definition": "Do not infer that DORA mandates open weights, a particular ownership architecture or a blanket ban on single providers. Check applicability, current obligations, concentration and exit provisions before making a legal conclusion.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:identity", "@type": "PracticeRule", "id": "identity", "name": "Use source-qualified identifiers", "definition": "BE-M0137 is Technology Constellation. expansion:137 refers to that source entry; pack:137 refers to Node-by-Node Correction and maps to BE-M0132. Bare numbers mean canonical IDs only when the context explicitly says so.", "status": "Reconciled application guidance" }, { "@id": "urn:business-engineer:practice-rule:deploy-gates", "@type": "PracticeRule", "id": "deploy-gates", "name": "Proposed four discovery gates", "definition": "Buyer and outcome authority; repeatable process and measurable acceptance; usable data and system access; viable operating economics and risk controls.", "status": "Proposed local default, not source-defined", "appliesToInstrument": [ "urn:business-engineer:instrument:deploy" ] }, { "@id": "urn:business-engineer:practice-rule:deploy-envelope", "@type": "PracticeRule", "id": "deploy-envelope", "name": "Proposed seven-part deployment envelope", "definition": "1 outcome and process; 2 data and semantics; 3 model and tool allocation; 4 integration and runtime; 5 authority and controls; 6 evaluation and observability; 7 economics and operating ownership. These are work packages, not a physical seven-layer architecture.", "status": "Proposed local default, not source-defined", "appliesToInstrument": [ "urn:business-engineer:instrument:deploy" ] }, { "@id": "urn:business-engineer:practice-rule:grid-extension", "@type": "PracticeRule", "id": "grid-extension", "name": "Proposed eleven-stage responsibility grid", "definition": "Discover, specify, prepare, build, integrate, validate, approve, deploy, operate, evaluate, evolve. Keep the same five accountability functions.", "status": "Proposed refinement, not recovered from the pack", "appliesToInstrument": [ "urn:business-engineer:instrument:responsibility-grid" ] }, { "@id": "urn:business-engineer:visual-standard:register-i", "@type": "VisualStandard", "id": "register-i", "name": "Register I: Data and Instruments", "definition": "Use when the artifact itself is data: dashboards, scorecards, model explorers and decks. Use a white ground, teal accents, legible comparisons and controls that help inspect the information.", "limits": "Do not place unlike units on one uncalibrated numeric axis. Use zero baselines for bar lengths; clearly label justified nonzero time-series axes. Charts must support their captions." }, { "@id": "urn:business-engineer:visual-standard:register-ii", "@type": "VisualStandard", "id": "register-ii", "name": "Register II: Editorial Ink", "definition": "Use for essay mechanism plates above argument headings. This supersedes the older card and warm-paper defaults in that context. One full plate should explain one identifiable mechanism.", "specification": "1240×900, white ground; ink #17171B, teal #0D6E6B, teal-2 #12908C, vermilion #C4342A, ochre #D19A2E, muted #7A756C, faint #D9D2C4. Georgia display, Inter or sans fallback, monospace ticks. Kicker y76, title y134 at44px, subtitle y178, rule y202, drawing y210–790, compression rule810/text840, footer876.", "requirements": [ "Draw objects and causal relationships; no boxes used merely as wrappers.", "Use restrained doubled strokes, bow, jitter, hatching and washes where they preserve legibility.", "Use drawn glyphs for arrows and checks, full-canvas plates, descriptive ordered filenames and no date on plates.", "Include top rule and masthead, title and italic description, mechanism, supporting labels, compression block with red bar, two numbered questions and footer takeaway when the format permits.", "For an essay plate family, use one template and cover the argument sections that need a drawing.", "Keep essay plates static; animation belongs to requested social exports or explicitly requested interactive work." ], "verification": "Check text-text, text-shape, clipping and drawing bounds using font metrics. Render the hero and dense plates at full resolution and inspect a contact sheet when supported. If preview is unavailable, state programmatic-only verification.", "metaphors": "Valves, clamps, pendulums, strata, buckets, roots and canopy, shared loads, tranches, bypassed moats, gears, wired gauges, trestles, balances, sieves, levers, apertures, gates and missing stair rungs. Select for causal fit, not decoration." }, { "@id": "urn:business-engineer:source-document:base", "@type": "SourceDocument", "id": "base", "name": "Original 136-model library", "filename": "Pasted markdown(20260909-133657).md", "sha256": "26ff6020f6d4b3f5998fd4b8656740df0be6c8c140da3d6d1e4d7c34da19125d", "definition": "User-supplied baseline. All 136 indexed model bodies are preserved; two source numbers are legacy aliases. Other operating practices are represented in instruments and practice rules." }, { "@id": "urn:business-engineer:source-document:expansion", "@type": "SourceDocument", "id": "expansion", "name": "Earlier 32-model conversational expansion", "sha256": "a04dcf63ea278ee3b68c53d06197603519b58606f167415b2c293a2ab70828aa", "definition": "Snapshot of the prior catalog. Entries 137–168 are proposed syntheses based on accessible conversations. This does not claim an exhaustive review of every prior conversation." }, { "@id": "urn:business-engineer:source-document:pack", "@type": "SourceDocument", "id": "pack", "name": "The Business Engineer Library Expansion Pack", "filename": "the-business-engineer-library-expansion-pack.md", "sha256": "ae92955d8b61d47926d534112f1bec1aa8ef2f7a8dbd3391ddc473cf6b720c8d", "definition": "All 125 numbered entries and all unnumbered additions are preserved as source records. Source numbers 137–261 belong to the pack namespace." }, { "@id": "urn:business-engineer:source-document:external-rdf", "@type": "SourceDocument", "id": "external-rdf", "name": "W3C RDF 1.1 Concepts", "url": "https://www.w3.org/TR/rdf11-concepts/", "definition": "Supports graph terms and RDF representation, not the empirical validity of the models.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-jsonld", "@type": "SourceDocument", "id": "external-jsonld", "name": "W3C JSON-LD 1.1", "url": "https://www.w3.org/TR/json-ld11/", "definition": "Supports JSON-LD syntax and linked-data representation.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-skos", "@type": "SourceDocument", "id": "external-skos", "name": "W3C SKOS Reference", "url": "https://www.w3.org/TR/skos-reference/", "definition": "Supports concept labels and semantic organization. A scoped source mapping is not asserted as owl:sameAs.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-ifrs", "@type": "SourceDocument", "id": "external-ifrs", "name": "IFRS 15 Illustrative Examples", "url": "https://www.ifrs.org/content/dam/ifrs/publications/html-standards/english/2026/issued/ifrs15-ie.html", "definition": "Used to check distinctions among receivables, contract assets and contract liabilities. Accounting classification is separate from analytical final-demand counting.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-valuation", "@type": "SourceDocument", "id": "external-valuation", "name": "Aswath Damodaran: Enterprise, Firm and Equity Values", "url": "https://pages.stern.nyu.edu/~adamodar/pdfiles/eqnotes/webcasts/multiplecalc/multiplecalc.pdf", "definition": "Used to check value boundaries, financing claims, cash and non-operating assets; ensure consistency with the associated cash flows.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-nist", "@type": "SourceDocument", "id": "external-nist", "name": "NIST AI Risk Management Framework", "url": "https://www.nist.gov/itl/ai-risk-management-framework", "definition": "Supports lifecycle evaluation and risk management. This voluntary framework does not validate a frozen suite or this catalog.", "status": "Primary reference for a limited distinction" }, { "@id": "urn:business-engineer:source-document:external-dora", "@type": "SourceDocument", "id": "external-dora", "name": "DORA official text: source to verify for a specific legal application", "url": "https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng", "definition": "The official page was access-blocked during this reconciliation. The pack is not treated as proof that DORA mandates an ownership architecture; no DORA compliance conclusion is made.", "status": "Not retrieved in this pass" }, { "@id": "urn:business-engineer:source-entry:base:1", "@type": "SourceEntry", "id": "base:1", "sourceNumber": 1, "name": "BE Thinking OS", "body": "The integrated cognitive architecture that functions simultaneously as a method for analysis, a filter for relevance, and a feedback loop for refinement. It converts complexity into deployable insight by forcing every input through structural, contextual, and pragmatic gates before any output is generated. This is the master operating system from which all other BE frameworks derive their coherence.\n- **Components**: Structural Filter (framework-first cognition), Contextual Gate (audience + timing + purpose), Compression Engine (minimum viable insight), Deployment Layer (actionable output formatting)\n- **Apply**: (1) Receive input/question → (2) Activate structural filter: what system is at play? → (3) Pass through contextual gate: who needs this, why now? → (4) Compress to load-bearing insight → (5) Format for deployment across audiences → (6) Feed output back into the loop for calibration\n- **Key Q**: \"Is this insight structurally grounded, contextually anchored, and deployable — or just interesting?\"", "sha256": "ad988b7e8c6e4c694211a7352669ca61c4610583b42e1bdc3abf4a44772bf3e0", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0001", "normalizedDefinition": "A repeatable analysis workflow connects structural hypotheses, audience context, evidence, compression and action, then revises the workflow after observing results.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:2", "@type": "SourceEntry", "id": "base:2", "sourceNumber": 2, "name": "Structural Thinking as Default", "body": "The discipline of always seeking the framework, system, or structural view before engaging with content. Most analysts start with data and hope structure emerges; the BE starts with structure and uses data to validate or falsify it. Structure is not a tool you reach for — it is the primary mode of cognition, the default lens through which every signal is processed.\n- **Components**: Framework Primacy (structure before content), System View (parts + relationships + feedback), Pattern Library (accumulated structural templates), Content Subordination (facts serve structure, not the reverse)\n- **Apply**: (1) When encountering any new information, pause before reacting → (2) Ask: what system does this belong to? → (3) Identify the structural skeleton: inputs, mechanisms, outputs, feedback → (4) Only then engage with the specific content details → (5) Validate whether the content confirms or challenges the structural hypothesis\n- **Key Q**: \"What is the structure here — and does the content confirm or break it?\"", "sha256": "025a33ff385b9ff4c0203c95e650921cce452068310c5383758350960e8327f7", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0002", "normalizedDefinition": "Begin with a provisional system hypothesis, identify relationships and feedback, and revise the structure when observations contradict it.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Treat an initial structure as a revisable hypothesis. Evidence can invalidate the framework itself; do not subordinate inconvenient observations to a preferred model." }, { "@id": "urn:business-engineer:source-entry:base:3", "@type": "SourceEntry", "id": "base:3", "sourceNumber": 3, "name": "Contextual Precision", "body": "The practice of anchoring every analysis in three coordinates: WHO it is for, WHY NOW it matters, and HOW it will be used. Without contextual precision, even structurally perfect analysis becomes noise. The same insight about AI adoption means entirely different things to a startup founder, a Fortune 500 CTO, and a policy regulator — and the BE must know which audience is being served before a single word is written.\n- **Components**: Audience Identification (WHO — role, constraints, mental model), Temporal Relevance (WHY NOW — what changed, what's at stake today), Deployment Mode (HOW — decision, strategy, communication, education)\n- **Apply**: (1) Before analyzing, explicitly define the audience → (2) Identify the temporal trigger: what made this relevant right now? → (3) Determine the output mode: is this for a decision, a strategy session, a presentation? → (4) Calibrate depth, language, and emphasis to match all three coordinates → (5) Strip anything that doesn't serve the specific context\n- **Key Q**: \"For whom, why now, and how will this be used?\"", "sha256": "cc07a2e871eb988c40df84f4bd1f3102ff7deb0a4f81db615e73aa8cc1aa08fc", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0003", "normalizedDefinition": "Choose the analysis and output according to the audience, decision, timing and intended use.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:4", "@type": "SourceEntry", "id": "base:4", "sourceNumber": 4, "name": "Meta-Compression", "body": "The ability to reduce any insight to its minimum viable form across three distinct levels: conceptual (the core idea), structural (the mechanism), and deployment (the action). Meta-compression is not simplification — it is distillation under pressure, where every surviving word must be load-bearing. The goal is maximum information density per unit of attention.\n- **Components**: Conceptual Compression (one-sentence essence), Structural Compression (mechanism in 2-3 steps), Deployment Compression (actionable takeaway in one line), Compression Ratio (how much was removed vs. retained)\n- **Apply**: (1) Start with the full analysis → (2) Extract the conceptual core: what is this really about in one sentence? → (3) Compress the mechanism: what causes what in 2-3 steps? → (4) Compress the deployment: what should the operator do? → (5) Test: does the compressed version still carry the structural insight, or has it become a platitude?\n- **Key Q**: \"Can I compress this further without losing the mechanism?\"", "sha256": "205f31b7d9702f94b1e09224b399dfc6d9455aef8d661c738bbaf783a6130f10", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0004", "normalizedDefinition": "Compress an explanation to the smallest set of mechanisms that preserves its reasoning, uncertainty and decision implications.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:5", "@type": "SourceEntry", "id": "base:5", "sourceNumber": 5, "name": "Layered Output Logic", "body": "The framework for structuring any analysis into three nested layers so that multiple audiences can extract value from the same output. Layer 1 is the macro mechanism (what is happening systemically), Layer 2 is the organizational impact (what it means for a specific company or sector), and Layer 3 is the operator takeaway (what to do on Monday morning). Each layer must stand alone while reinforcing the others.\n- **Components**: Macro Layer (industry/system-level mechanism), Organizational Layer (company/team-level impact), Operator Layer (individual-level action), Vertical Coherence (all three layers tell the same structural story)\n- **Apply**: (1) Identify the macro mechanism first — the systemic force at work → (2) Translate downward: how does this mechanism hit a specific organization? → (3) Translate again: what does this mean for the individual operator's next decision? → (4) Verify vertical coherence: do all three layers point in the same direction? → (5) Format output so readers can enter at any layer\n- **Key Q**: \"Does this analysis work for the strategist, the manager, AND the operator — simultaneously?\"", "sha256": "bdefa91cb956c61c46834fddc74eca348587ffec98ee4c65aa5d025cca0aa936", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0005", "normalizedDefinition": "Represent one analysis at several levels of detail while keeping definitions, evidence and conclusions consistent across levels.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:6", "@type": "SourceEntry", "id": "base:6", "sourceNumber": 6, "name": "Pragmatic Rigor", "body": "The commitment to prioritizing mechanism, causality, and feedback loops over narrative polish or rhetorical elegance. In the BE system, every claim must be \"load-bearing\" — meaning it must carry structural weight and be falsifiable. An insight that sounds good but lacks a causal mechanism is worse than no insight at all, because it creates false confidence.\n- **Components**: Load-Bearing Test (does this claim do structural work?), Mechanism Requirement (what causes what?), Feedback Identification (what reinforces or dampens this?), Falsifiability Check (what would disprove this?)\n- **Apply**: (1) For every claim in your analysis, apply the load-bearing test: remove it and see if the argument collapses → (2) If the argument survives without it, the claim is decorative — cut it → (3) For surviving claims, verify the causal mechanism is explicit → (4) Identify feedback loops: does this effect amplify or dampen itself? → (5) State what evidence would disprove the claim\n- **Key Q**: \"Is every claim in this analysis load-bearing — or am I decorating?\"", "sha256": "cc03f65a890afdecd767ce3500a41e26d94145f4f0f1cad4de68e715e169b89b", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0006", "normalizedDefinition": "Use enough rigor to distinguish decision-relevant alternatives, proportionate to uncertainty, stakes and the cost of delay.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:7", "@type": "SourceEntry", "id": "base:7", "sourceNumber": 7, "name": "Edge Framing", "body": "The systematic practice of interrogating consensus to surface what the market or conventional wisdom has mispriced, overlooked, or gotten wrong. Edge Framing is not contrarianism for its own sake — it is the disciplined search for structural insights that the majority has failed to incorporate. The value of any analysis is proportional to how much it diverges from what the audience already believes.\n- **Components**: Consensus Mapping (what does everyone already believe?), Mispricing Detection (where is the gap between belief and structural reality?), Overlooked Variable Identification (what factor is being systematically ignored?), Contrarian Validation (is the contrarian view structurally supported or just provocative?)\n- **Apply**: (1) Map the consensus view on any topic explicitly → (2) Identify the structural assumptions embedded in that consensus → (3) Stress-test each assumption: what would have to be true for this to hold? → (4) Look for the overlooked variable or mispriced factor → (5) Validate: is the edge structural (backed by mechanism) or just rhetorical? → (6) If structural, frame the insight around the gap between consensus and reality\n- **Key Q**: \"What has the consensus mispriced, overlooked, or gotten structurally wrong?\"", "sha256": "e1dda40eb66567aa91a54adfb5b633e3f3b13eb60383c5838029d16166770f79", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0007", "normalizedDefinition": "Find a consequential difference between the prevailing interpretation and a mechanism supported by discriminating evidence.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Analytical value depends on better understanding or decisions, not distance from consensus. Confirming a well-supported consensus can be the correct result." }, { "@id": "urn:business-engineer:source-entry:base:8", "@type": "SourceEntry", "id": "base:8", "sourceNumber": 8, "name": "Integration Engine", "body": "The cognitive ability to connect insights across technology, economics, behavior, narrative, and incentive structures into a unified analytical view. Most analysis stays siloed — a tech analyst misses the behavioral dimension, an economist ignores the narrative layer. The Integration Engine forces cross-domain synthesis, because real-world outcomes are determined by the interaction of all five domains simultaneously.\n- **Components**: Technology Layer (capabilities, constraints, trajectories), Economics Layer (costs, margins, incentive structures), Behavior Layer (user psychology, adoption patterns, resistance), Narrative Layer (stories that shape perception and capital flows), Incentive Layer (what actors are actually rewarded for doing)\n- **Apply**: (1) Analyze any phenomenon through each of the five lenses independently → (2) Map the interactions: how does technology reshape economics? How do incentives distort narrative? → (3) Identify the dominant layer: which one is driving outcomes right now? → (4) Identify the lagging layer: which one hasn't caught up yet? → (5) The gap between the dominant and lagging layer is where the insight lives\n- **Key Q**: \"Which domain is driving this outcome — and which domain hasn't caught up yet?\"", "sha256": "7621012d39f23538562bb2c7535f3a0da018f55d604606e5224bc109a4ac2a8e", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0008", "normalizedDefinition": "Combine useful models through their explicit assumptions and relationships; shared premises do not provide independent corroboration.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:9", "@type": "SourceEntry", "id": "base:9", "sourceNumber": 9, "name": "Strategic Narrative Compression", "body": "The three-phase framework for communicating complex structural analysis: Orient (what is at stake and for whom), Illuminate (the mechanism — what causes what), and Activate (actionable implications — what to do about it). This is not storytelling — it is the deployment protocol for structural insight, ensuring that every communication moves the audience from context to mechanism to action.\n- **Components**: Orient Phase (stakes, audience, context — why should they care?), Illuminate Phase (mechanism, causality, structure — what is actually happening?), Activate Phase (implications, decisions, next moves — what should they do?)\n- **Apply**: (1) Open by orienting the audience: what's at stake and why it matters now → (2) Illuminate the mechanism: explain the structural driver in 2-3 steps → (3) Activate with implications: give the audience a concrete next move or decision framework → (4) Test: can someone who reads only the Orient phase decide if they need to read further? → (5) Test: can someone who reads only the Activate phase take action?\n- **Key Q**: \"Have I oriented, illuminated, and activated — or just informed?\"", "sha256": "7baf637dff00503b0f61c713430909eff514e7da3f07f2296be729edc90f750c", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0009", "normalizedDefinition": "Express the mechanism, stakes and action in a coherent narrative without removing qualifications that could change the conclusion.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:10", "@type": "SourceEntry", "id": "base:10", "sourceNumber": 10, "name": "Calibration Loop", "body": "The iterative process of refining the same insight across multiple variants — sharper, more contrarian, more compressed, more audience-specific — until maximum clarity is achieved. The first draft of any structural insight is never the best version. The Calibration Loop forces deliberate iteration not on polish but on precision, testing whether the insight survives compression, inversion, and reframing.\n- **Components**: Variant Generation (produce 3-5 versions of the same insight), Sharpness Pass (remove every non-load-bearing word), Contrarian Pass (invert the insight — does the opposite hold?), Compression Pass (cut by 50% — what survives?), Audience Pass (reframe for a different stakeholder)\n- **Apply**: (1) State the initial insight → (2) Generate a sharper version: fewer words, more precision → (3) Generate a more contrarian version: what would the strongest critic say? → (4) Generate a more compressed version: cut it in half → (5) Compare all variants: which one is structurally strongest? → (6) Adopt the winner and repeat if needed\n- **Key Q**: \"Is this the sharpest, most precise version of this insight — or can I compress and calibrate further?\"", "sha256": "3bc3d1c08f4e784495ce8e235f8d9464d26b637dc850226d6a368d8e9275d7a0", "sourceCategory": "I. THE BE THINKING OS (Meta-Cognitive Architecture)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0010", "normalizedDefinition": "Compare a prior prediction with the observed result and revise the assumption or model that produced the error.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:11", "@type": "SourceEntry", "id": "base:11", "sourceNumber": 11, "name": "Structural vs Reactive Thinking", "body": "The foundational distinction between two cognitive modes: reactive thinking (Event → Response) and structural thinking (Event → System → Mechanism → Implication). Most professionals operate reactively — they see an event and jump to a response. The BE operates structurally — every event is a symptom of a deeper system, and the response must address the mechanism, not the symptom. This distinction is the single most important upgrade in analytical capability.\n- **Components**: Reactive Chain (Event → Emotional/Surface Response → Action), Structural Chain (Event → What system produced this? → What mechanism is operating? → What are the second-order implications?), Mode Detection (recognizing which mode you are currently in)\n- **Apply**: (1) When an event occurs (market move, product launch, policy change), catch yourself before reacting → (2) Ask: what system produced this event? → (3) Identify the mechanism: what causal chain is at work? → (4) Map implications: if this mechanism continues, what happens next? → (5) Only then decide on a response — which now addresses the mechanism, not the symptom\n- **Key Q**: \"Am I reacting to the event — or understanding the system that produced it?\"", "sha256": "84a2341505f713a56d73a258c6f5ec3e383fa40c99aba0643d90bca59a4249ad", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0011", "normalizedDefinition": "Distinguish an event from the system generating it, while allowing events to reveal a structural change.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:12", "@type": "SourceEntry", "id": "base:12", "sourceNumber": 12, "name": "Structural Thinking Workflow", "body": "The five-step operational sequence for converting any observation into structural insight: Pattern Recognition (what recurs?), Structural Diagnosis (what system produces this pattern?), Constraint Identification (what limits the system?), Leverage Point Discovery (where does small input create large output?), and Second-Order Implications (what happens next that no one is discussing?). This workflow turns the BE's structural instinct into a repeatable process.\n- **Components**: Pattern Recognition (recurring signals across domains), Structural Diagnosis (the system architecture that generates the pattern), Constraint Identification (the binding limit on the system), Leverage Point (the high-impact intervention point), Second-Order Implications (downstream effects most analysts miss)\n- **Apply**: (1) Observe: collect signals and identify recurring patterns → (2) Diagnose: hypothesize the structural system generating those patterns → (3) Constrain: find the binding constraint — the single factor most limiting the system → (4) Leverage: identify where minimal intervention would shift the most → (5) Project: map second-order implications — the consequences of consequences\n- **Key Q**: \"What is the binding constraint, and where is the leverage point?\"", "sha256": "89141254276d7f6acdeb69a5f55d900fcf20e06761bbe814525689037d96c301", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0012", "normalizedDefinition": "Map the actor, system boundary, relationships, constraints and interventions, then test the proposed mechanism against alternatives.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:13", "@type": "SourceEntry", "id": "base:13", "sourceNumber": 13, "name": "Reality Gap Analysis", "body": "A diagnostic framework that identifies the chasm between what markets believe (the prevailing narrative) and what structural forces will actually deliver (the reality). Markets are narrative-driven in the short term and structurally determined in the long term. The Reality Gap is where mispricing lives — and where the most valuable insights are found. When narrative and structure diverge, structure always wins eventually.\n- **Components**: Narrative Layer (what the market/consensus currently believes and prices), Structural Layer (what the underlying forces — capital flows, technology curves, regulatory vectors — actually indicate), Gap Measurement (size and direction of divergence), Convergence Timeline (when reality forces narrative correction)\n- **Apply**: (1) Map the dominant narrative: what does the consensus believe about this market/company/trend? → (2) Map the structural forces: capital requirements, technology constraints, regulatory direction, competitive dynamics → (3) Measure the gap: where and how much do narrative and structure diverge? → (4) Estimate convergence: when will reality force a correction? → (5) Position accordingly: the gap IS the insight\n- **Key Q**: \"Where is the gap between what the market believes and what structural forces will deliver?\"", "sha256": "ccd8747aa175f16cfe13af926c067650206a6726661f6e464ef7fc32af9d3b97", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0013", "normalizedDefinition": "Compare stated intentions, visible behavior and underlying incentives to identify consequential gaps between claims and operation.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Narratives can alter investment, incentives and the structure itself. Convergence is contingent and may not occur within the decision horizon; do not assert that structure always wins." }, { "@id": "urn:business-engineer:source-entry:base:14", "@type": "SourceEntry", "id": "base:14", "sourceNumber": 14, "name": "Hidden Driver Detection", "body": "A three-layer diagnostic for understanding why organizations and leaders make seemingly puzzling decisions. Layer 1 is the Stated Reason (the PR version — what they say publicly). Layer 2 is the Plausible Reason (the analyst take — what smart observers assume). Layer 3 is the Structural Driver (the existential imperative — what they must do given the constraints they face). The real explanation almost always lives at Layer 3, and reaching it requires peeling back the first two layers deliberately.\n- **Components**: Layer 1 — Stated Reason (public narrative, press release, earnings call language), Layer 2 — Plausible Reason (informed analyst interpretation, industry logic), Layer 3 — Structural Driver (existential constraint, competitive imperative, survival logic)\n- **Apply**: (1) Note the stated reason for any major decision → (2) Apply analyst logic: what's the plausible business reason? → (3) Go deeper: what existential threat or structural constraint makes this decision inevitable? → (4) Test Layer 3 by asking: \"Would they do this even if the stated and plausible reasons were false?\" → (5) If yes, you've found the structural driver\n- **Key Q**: \"What is the existential imperative that makes this decision structurally inevitable?\"", "sha256": "7604501e8001cc9b1955dee1a8c5b79e742ac1f4f7762115bfb58f747e459b69", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0014", "normalizedDefinition": "Look for overlooked variables or relationships that can explain an observation better than the apparent driver.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Generate competing explanations including mistakes, agency conflicts and incomplete information. Hidden motives and existential imperatives are hypotheses, not facts inferred from a puzzling decision." }, { "@id": "urn:business-engineer:source-entry:base:15", "@type": "SourceEntry", "id": "base:15", "sourceNumber": 15, "name": "Constraint Mapping", "body": "The method for finding the single binding constraint in any system — the one factor that, if relaxed, would unlock the most value, and if tightened, would break the system first. It deploys three tests: the Bottleneck Test (what breaks first if you scale 10x?), the Substitution Test (can this be replaced, or is it truly irreplaceable?), and the Veto Test (who or what can single-handedly block everything?). Most analysts list many constraints; the BE finds the one that actually binds.\n- **Components**: Bottleneck Test (scale 10x — what breaks first?), Substitution Test (can this factor be replaced or routed around?), Veto Test (who or what has unilateral blocking power?), Binding Constraint (the one constraint that all three tests point to)\n- **Apply**: (1) List all apparent constraints on the system → (2) Apply the Bottleneck Test to each: if this system scaled 10x, which constraint would break first? → (3) Apply the Substitution Test: which of these constraints is truly irreplaceable? → (4) Apply the Veto Test: who or what can single-handedly block progress? → (5) The constraint that fails all three tests (breaks first, can't be substituted, has veto power) is the binding constraint → (6) All strategy should address this constraint first\n- **Key Q**: \"What is the single binding constraint — and what happens if it's relaxed or tightened?\"", "sha256": "3fe84c9ead459fc42cbc4db10c60d35f5e25abe296915949a31a59eb94b13330", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0015", "normalizedDefinition": "Identify which resource, rule, authority or dependency limits a specified outcome under current conditions.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Find the constraint or jointly binding set relevant to a stated objective and horizon. A bottleneck need not also be irreplaceable and possess veto power. Model 130 explicitly permits simultaneous constraints." }, { "@id": "urn:business-engineer:source-entry:base:16", "@type": "SourceEntry", "id": "base:16", "sourceNumber": 16, "name": "Power Distribution Analysis", "body": "A framework for mapping where real leverage resides in any system, organization, or market. It distinguishes three types of power: Veto Power (the ability to block outcomes without proposing alternatives), Compulsion Power (the ability to force action regardless of consent), and Rule-Making Power (the ability to reshape the rules of the game itself). Understanding which actors hold which type of power reveals who actually controls outcomes — often very different from who appears to be in charge.\n- **Components**: Veto Power (capacity to block without offering alternatives), Compulsion Power (capacity to force action — regulatory, financial, contractual), Rule-Making Power (capacity to redefine the game — platform rules, standards, regulations), Power Map (visual distribution of all three types across actors)\n- **Apply**: (1) Identify all actors in the system → (2) For each actor, assess: can they block outcomes (veto)? → (3) Can they force action (compulsion)? → (4) Can they change the rules (rule-making)? → (5) Map the distribution: who holds which types of power? → (6) Identify the dominant power holder — the actor with the most types or the most consequential type → (7) Strategy must account for or work through the dominant power holder\n- **Key Q**: \"Who can block, who can force, and who can rewrite the rules — and are they the same actor?\"", "sha256": "1befffee99ffefc525326c154d41b1352fb4b998478d532a5d13ea3c6c93633b", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0016", "normalizedDefinition": "Map who can allocate resources, set terms, withhold permission or redirect value, and how those powers depend on others.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:17", "@type": "SourceEntry", "id": "base:17", "sourceNumber": 17, "name": "System Fragmentation Mapping", "body": "A diagnostic framework that reveals where apparent integration masks actual separation in organizations, markets, or technologies. It operates across four states: Visible Integration (genuinely connected), Hidden Fragmentation (appears integrated but is structurally separate), Cosmetic Integration (surface-level connection with no real coordination), and Deep Fragmentation (fundamentally separate systems held together only by branding or narrative). Most large organizations and markets are far more fragmented than they appear.\n- **Components**: Visible Integration (real coordination, shared data, unified incentives), Hidden Fragmentation (separate systems behind unified interface), Cosmetic Integration (shared brand/narrative but independent operations), Deep Fragmentation (fundamentally separate with no real connection), Fragmentation Score (assessment of true integration level)\n- **Apply**: (1) Take any system that appears integrated (a conglomerate, a platform, a market) → (2) Test data flow: does information actually move across units in real time? → (3) Test incentive alignment: are all parts rewarded for the same outcomes? → (4) Test operational dependency: would removing one part break the others? → (5) Classify each connection as visible, hidden, cosmetic, or deeply fragmented → (6) The true fragmentation level reveals vulnerability and opportunity\n- **Key Q**: \"Is this system genuinely integrated — or is the integration cosmetic?\"", "sha256": "eab5d379409eedacf7197d71283d9519a6134b76a7c7ee5b45b8691be133857b", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0017", "normalizedDefinition": "Locate disconnected responsibilities, information or processes whose interfaces create cost, failure or an integration opportunity.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:18", "@type": "SourceEntry", "id": "base:18", "sourceNumber": 18, "name": "Structural Reality Framework", "body": "A four-layer cascade model showing how higher-order structural forces constrain all layers below them: Geopolitics (international power dynamics) → Policy (government decisions) → Infrastructure (physical and digital systems) → Markets (prices, competition, business outcomes). A market analyst who ignores the geopolitical layer is building on sand. Each layer constrains the degrees of freedom available to all layers beneath it.\n- **Components**: Geopolitical Layer (international power, alliances, conflicts, resource control), Policy Layer (regulation, taxation, subsidies, trade rules), Infrastructure Layer (physical systems, supply chains, digital networks, energy grids), Market Layer (prices, competition, business models, consumer behavior)\n- **Apply**: (1) Start at the top: what are the geopolitical forces relevant to this issue? → (2) Move to policy: how have those geopolitical forces shaped or constrained government action? → (3) Move to infrastructure: what physical/digital systems enable or limit execution? → (4) Finally reach markets: how do all three layers above constrain what businesses can actually do? → (5) Never analyze a lower layer without checking the constraints imposed by all layers above\n- **Key Q**: \"What higher-layer constraints am I ignoring that will override my market-level analysis?\"", "sha256": "edeb98fa56429724ae0b3342884a9c8e49904c6aaa7d86003cab0509e4988b02", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0018", "normalizedDefinition": "Reconstruct a system from constraints, incentives, power, dependencies and observable behavior rather than relying on its public description.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Use geopolitics, policy, infrastructure and markets as interacting layers. Draw feedback upward as well as constraints downward; no universal hierarchy resolves every case." }, { "@id": "urn:business-engineer:source-entry:base:19", "@type": "SourceEntry", "id": "base:19", "sourceNumber": 19, "name": "Constraint Cascade Principle", "body": "The principle that upstream structural misalignment is always more lethal than downstream competitive inefficiency. A company can have the best product, the best team, and the best strategy — and still fail if geopolitical forces, policy decisions, or infrastructure limitations work against it. This principle forces the analyst to check upstream layers before optimizing downstream ones, preventing the common error of perfecting a strategy that is structurally doomed.\n- **Components**: Upstream Audit (geopolitical and policy alignment check), Downstream Assessment (competitive and operational efficiency), Cascade Direction (problems always flow downward from higher layers), Lethality Ranking (geopolitical misalignment > policy misalignment > infrastructure gaps > competitive weakness)\n- **Apply**: (1) Before any competitive analysis, check the geopolitical layer: is the environment stable? → (2) Check the policy layer: are regulations enabling or blocking? → (3) Check the infrastructure layer: can the physical/digital systems support the strategy? → (4) Only then assess competitive positioning → (5) If any upstream layer is misaligned, fixing downstream layers is futile — address the cascade from the top\n- **Key Q**: \"Is there an upstream constraint that makes all my downstream optimization pointless?\"", "sha256": "19cda11acb0b2427ba4646027dd40a1f13b47542326e5470c2d4a75a17f2bbf3", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0019", "normalizedDefinition": "Removing one limiting constraint can expose another; model the next binding constraint and possible simultaneous limits before investing.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Upstream constraints can dominate, but not always. Test their actual causal reach, the available adaptations and the consequences of downstream failure; avoid a fixed lethality ranking." }, { "@id": "urn:business-engineer:source-entry:base:20", "@type": "SourceEntry", "id": "base:20", "sourceNumber": 20, "name": "Perspective-First Analysis", "body": "The principle of starting with qualitative territory understanding to generate hypotheses before designing targeted measurement. Most analysts reach for data first and hope insight emerges. The BE starts with perspective — developing a qualitative understanding of the territory through observation, pattern recognition, and structural reasoning — then uses that perspective to determine what data actually matters. This prevents the common trap of measuring everything and understanding nothing.\n- **Components**: Qualitative Territory Scan (observe, listen, pattern-match before measuring), Hypothesis Generation (form structural hypotheses from qualitative understanding), Targeted Measurement Design (design data collection to test specific hypotheses), Perspective-Data Feedback (let measurement refine perspective, let perspective redirect measurement)\n- **Apply**: (1) Before pulling data, spend time understanding the territory qualitatively: who are the players, what are the dynamics, what feels off? → (2) Generate 2-3 structural hypotheses about what's driving outcomes → (3) Design targeted measurements that would confirm or falsify each hypothesis → (4) Collect and analyze only that data → (5) Let the results refine your perspective, then iterate\n- **Key Q**: \"Do I understand the territory well enough to know what to measure — or am I measuring blindly?\"", "sha256": "d9019daebca414929a73abef13e9f1337080276d136357c57858cd495ec70b10", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0020", "normalizedDefinition": "State whose decision and exposure the analysis serves, then inspect the same system from other consequential positions.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:21", "@type": "SourceEntry", "id": "base:21", "sourceNumber": 21, "name": "Territory Mapping", "body": "A four-question diagnostic for rapidly understanding any competitive, market, or strategic landscape before attempting analysis. The four questions are: What game is being played? (the nature of the competition), Who are the real players? (not the visible ones — the ones with actual power), What drives behavior? (incentives, constraints, fears), and What are the structural forces? (technology curves, capital flows, regulation). This is the BE's default opening move when entering unfamiliar territory.\n- **Components**: Game Identification (what type of competition is this — zero-sum, positive-sum, infinite?), Player Mapping (who has real power, not just visibility), Behavior Drivers (incentives, constraints, fears that determine action), Structural Forces (technology, capital, regulation, demographics shaping the landscape)\n- **Apply**: (1) Ask: what game is being played here? Is it winner-take-all, cooperative, or something else? → (2) Map the real players: who has veto, compulsion, or rule-making power? → (3) Identify behavior drivers: what are the key actors actually incentivized to do? → (4) Map structural forces: which large-scale trends are shaping the playing field? → (5) Synthesize: the intersection of game type, player incentives, and structural forces reveals the true territory\n- **Key Q**: \"What game is being played, by whom, driven by what, and shaped by which structural forces?\"", "sha256": "af38a5b4849a847cf606995f85d7177065ad14ce7874b3b4975dfbb6ba8b814a", "sourceCategory": "II. STRUCTURAL ANALYSIS TOOLKIT", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0021", "normalizedDefinition": "Map the relevant market terrain, actors, interfaces and constraints before choosing a strategic route.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:22", "@type": "SourceEntry", "id": "base:22", "sourceNumber": 22, "name": "Grand Strategy Framework", "body": "The master framework for strategic planning: Territory → Map → Routes. First, understand the landscape (the actual environment, not the perceived one). Second, derive the strategy (the map — your interpretation of the territory that guides decisions). Third, execute the tactics (the routes — specific paths through the territory). Most organizations start with routes (tactics) and work backward; the BE starts with territory and works forward. Strategy without territory understanding is just guessing with confidence.\n- **Components**: Territory (deep understanding of the actual competitive, technological, and regulatory landscape), Map (the strategic interpretation — your reading of the territory that guides resource allocation), Routes (tactical execution paths — the specific moves, sequences, and contingencies)\n- **Apply**: (1) Invest heavily in territory understanding: what is the actual landscape? Use Territory Mapping, Structural Reality Framework, and Constraint Mapping → (2) Derive your map: based on the territory, what is your strategic interpretation? Where are the opportunities, threats, and leverage points? → (3) Design routes: what specific tactical paths will you take? In what sequence? With what contingencies? → (4) Continuously update: as the territory shifts, the map must shift, and routes must adapt\n- **Key Q**: \"Am I building strategy from territory understanding — or am I guessing the territory from my preferred tactics?\"", "sha256": "6e7c99d61d6dcd1624ac75f454b354a9528b9d31241694baac1f344c70a60f5e", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0022", "normalizedDefinition": "Connect a long-term objective to the terrain, resources, capabilities, sequencing and adaptation needed to reach it.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:23", "@type": "SourceEntry", "id": "base:23", "sourceNumber": 23, "name": "Time Horizon Analysis", "body": "The discipline of simultaneously analyzing and planning across three time horizons: Immediate (0-2 years — survival and execution), Mid-Term (3-5 years — positioning and capability building), and Long-Term (6-10+ years — structural bets and transformation). The critical insight is that all three horizons must be managed simultaneously, not sequentially. An organization that only focuses on the immediate is always surprised; one that only focuses on the long-term never ships.\n- **Components**: Immediate Horizon (0-2yr: current revenue, operational execution, quick wins), Mid-Term Horizon (3-5yr: market positioning, capability building, competitive moats), Long-Term Horizon (6-10+yr: structural bets, technology shifts, ecosystem evolution), Horizon Balancing (managing all three simultaneously without neglecting any)\n- **Apply**: (1) For any strategic question, explicitly analyze across all three horizons → (2) Immediate: what must we do in the next 0-2 years to survive and generate cash? → (3) Mid-Term: what capabilities and positions must we build in 3-5 years? → (4) Long-Term: what structural bets should we place for 6-10+ years? → (5) Check for conflicts: does the immediate plan undermine the long-term bet? → (6) Allocate attention and resources across all three\n- **Key Q**: \"Am I managing all three time horizons simultaneously — or sacrificing the future for the present (or vice versa)?\"", "sha256": "0e1ab49b6cecbdbf076d50520e9b2ad81bbd863be2d25b8abea2a44f1e195fce", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0023", "normalizedDefinition": "Separate decisions by the time needed to act, learn, recover investment and reverse a mistake.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The stated horizon lengths are examples. Choose horizons around the actual asset life, decision window and uncertainty-resolution schedule." }, { "@id": "urn:business-engineer:source-entry:base:24", "@type": "SourceEntry", "id": "base:24", "sourceNumber": 24, "name": "Contextual Map (2x2)", "body": "A strategic prioritization matrix that plots Strategic Impact (high/low) against Uncertainty (high/low) to create four action quadrants: Invest (high impact, low uncertainty — commit resources now), Hedge (high impact, high uncertainty — maintain optionality), Track (low impact, low uncertainty — monitor but don't over-invest), and Scout (low impact, high uncertainty — explore cheaply for hidden potential). This framework prevents the twin errors of over-investing in certainties and ignoring wild cards.\n- **Components**: Invest Quadrant (high strategic impact + low uncertainty = commit fully), Hedge Quadrant (high strategic impact + high uncertainty = maintain optionality, place calculated bets), Track Quadrant (low strategic impact + low uncertainty = monitor with minimal resources), Scout Quadrant (low strategic impact + high uncertainty = cheap exploration, watch for signals)\n- **Apply**: (1) List all strategic initiatives, trends, or decisions on the table → (2) Rate each on Strategic Impact (how much does this affect our future?) and Uncertainty (how confident are we in the outcome?) → (3) Place each in the appropriate quadrant → (4) Invest: allocate significant resources now → Hedge: build optionality, don't commit fully → Track: maintain awareness with minimal cost → Scout: run cheap experiments, watch for signal changes → (5) Reassess quarterly — quadrant placement shifts as uncertainty resolves\n- **Key Q**: \"Am I allocating resources based on the actual combination of impact and uncertainty — or defaulting to what feels safe?\"", "sha256": "c4dece0c67aeb165cd3b34ba0871042e74c54b6daaffa5f02a0a1cc893cd30f5", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0024", "normalizedDefinition": "Use two explicit, decision-relevant axes to compare positions; the map is a simplification whose dimensions and boundaries must be justified.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:25", "@type": "SourceEntry", "id": "base:25", "sourceNumber": 25, "name": "Tactical Routes Framework", "body": "The operational framework for translating strategic maps into executable tactical paths. It begins with a three-part Assessment (External environment, Internal capabilities, Constraints) and then selects from four route types: Vertical (go deeper in current domain), Horizontal (expand across adjacent domains), Diagonal (combine vertical and horizontal simultaneously), and Combination (orchestrate multiple routes in sequence or parallel). The route must match the assessment — not the ambition.\n- **Components**: External Assessment (market, competition, technology, regulation), Internal Assessment (capabilities, resources, culture, leadership), Constraint Assessment (time, capital, talent, regulatory limits), Route Selection (Vertical: deepen / Horizontal: broaden / Diagonal: both / Combination: orchestrated sequence)\n- **Apply**: (1) Conduct external assessment: what does the market, competitive, and regulatory landscape look like? → (2) Conduct internal assessment: what are our real capabilities, not aspirational ones? → (3) Map constraints: what are the hard limits on time, capital, talent? → (4) Select the route that matches the assessment: vertical if depth is the advantage, horizontal if breadth, diagonal if speed demands both, combination if resources allow orchestration → (5) Sequence and execute\n- **Key Q**: \"Does my tactical route match my actual assessment — or my ambition?\"", "sha256": "e72040c1dab58244a4201a08d10a1212361ca75b87a83d713db69a4d4eb4749f", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0025", "normalizedDefinition": "Translate a strategic destination into feasible alternative routes with milestones, dependencies and fallback choices.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:26", "@type": "SourceEntry", "id": "base:26", "sourceNumber": 26, "name": "Multi-Horizon Strategic Map", "body": "A resource allocation framework that operationalizes Time Horizon Analysis into a concrete spending and attention model: 70% of resources to the Immediate Horizon (current operations and revenue), 20% to the Mid-Term Horizon (capability building and positioning), and 10% to the Long-Term Horizon (structural bets and transformation experiments). The critical discipline is executing all three allocations simultaneously, not sequentially, and reviewing the ratio as conditions change.\n- **Components**: 70% Immediate Allocation (operations, current revenue, optimization), 20% Mid-Term Allocation (new capabilities, market positioning, competitive moats), 10% Long-Term Allocation (moonshots, structural bets, transformation), Simultaneous Execution (all three run in parallel, not in sequence), Ratio Review (quarterly adjustment based on changing conditions)\n- **Apply**: (1) Audit current resource allocation: where is time, money, and talent actually going? → (2) Redistribute toward the 70/20/10 target → (3) Ensure each allocation has a clear owner and success metrics → (4) Run all three in parallel — do not wait for immediate results before starting mid-term → (5) Review the ratio quarterly: a crisis may justify 90/8/2; a stable period may allow 60/25/15 → (6) Never let any horizon go to zero\n- **Key Q**: \"Is my resource allocation balanced across all three horizons — or has the immediate consumed everything?\"", "sha256": "5676c3b7a0435099743a522f55af3028e57906a9449ae1c9f9b485f8b1497651", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0026", "normalizedDefinition": "Connect near-term execution, medium-term capability building and longer-term options without assuming one horizon determines another.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The 70/20/10 allocation is illustrative, not an optimized or universal recommendation. Resource allocation depends on survival needs, opportunity quality, constraints and risk." }, { "@id": "urn:business-engineer:source-entry:base:27", "@type": "SourceEntry", "id": "base:27", "sourceNumber": 27, "name": "Contextual Adaptability Framework", "body": "A framework for assessing organizational fitness not just to the current environment but to shifting environments. It examines three dimensions: Forces (what external pressures are changing?), Capabilities (does the organization have the skills and structures to respond?), and Horizons (is the organization tracking where the environment is heading, not just where it is?). Organizations that score high on all three dimensions survive transitions; those that miss any one dimension get disrupted.\n- **Components**: Forces Assessment (what external pressures — technological, regulatory, competitive, social — are shifting?), Capability Assessment (does the organization have the skills, structure, and culture to respond?), Horizon Assessment (is the organization looking far enough ahead to anticipate shifts?), Adaptability Score (composite fitness across all three dimensions)\n- **Apply**: (1) Map current forces: what external pressures are actively shifting? → (2) Assess capabilities: can the organization respond to these shifts with current skills and structure? → (3) Assess horizons: is the organization tracking emerging forces, not just current ones? → (4) Identify the weakest dimension — that's the vulnerability → (5) Design interventions to strengthen the weakest dimension before a crisis forces it → (6) Reassess as the environment shifts\n- **Key Q**: \"Are we fit for the current environment AND the one that's emerging — or only the one we grew up in?\"", "sha256": "87833dd1d0fa5fa34d56684c85dcc8df9aab704a56986535210aedcb8692705e", "sourceCategory": "III. GRAND STRATEGY & PLANNING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0027", "normalizedDefinition": "Adapt a strategy when its contextual assumptions change, using explicit signals rather than reacting to every fluctuation.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:28", "@type": "SourceEntry", "id": "base:28", "sourceNumber": 28, "name": "Strategy Lever Framework", "body": "The five-step market entry and growth sequence: (1) Blue Sea — find the smallest viable premium niche, (2) Niche Down — target the tightest coherent segment within it, (3) MVA — define the Minimum Viable Audience that can sustain the business, (4) Adjacent Niches — expand systematically into neighboring segments, (5) Scale — build infrastructure and models for broader reach. This is the BE's core go-to-market philosophy: start impossibly small, prove value, and expand from strength.\n- **Components**: Blue Sea (identify premium niche where competition is thin), Niche Down (select the tightest segment within that niche), MVA (define the smallest audience that sustains the business), Adjacent Niches (map neighboring segments for systematic expansion), Scale (build the infrastructure and model for broader reach)\n- **Apply**: (1) Scan the landscape for underserved premium niches (Blue Sea) → (2) Within that niche, identify the tightest coherent segment you can dominate (Niche Down) → (3) Define the Minimum Viable Audience — the smallest group whose problem you can solve profitably (MVA) → (4) Serve them obsessively until you have proof of value → (5) Map adjacent niches and expand using existing credibility → (6) Only scale when the model has been validated across multiple niches\n- **Key Q**: \"Am I starting small enough — or am I trying to scale before I've proven value to the tightest possible audience?\"", "sha256": "1ff0f6e2c3805b74adf7db7900a4af6ba4b1fa1b3a4269f67613fd72246220e6", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0028", "normalizedDefinition": "Find interventions that can materially change a strategic outcome and assess their feasibility, cost and second-order effects.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:29", "@type": "SourceEntry", "id": "base:29", "sourceNumber": 29, "name": "Blue Sea Strategy", "body": "A market entry philosophy that inverts Blue Ocean Strategy. Instead of seeking uncontested mass markets, Blue Sea starts from the smallest viable premium niche and expands organically. The logic: mass-market blue oceans attract fast followers and require massive capital; premium niches are defensible, generate high margins early, and fund organic expansion. The goal is not to avoid competition but to compete where you have structural advantage from day one.\n- **Components**: Premium Niche Identification (where can you charge premium prices to a small, underserved group?), Structural Advantage Check (what gives you a natural edge in this niche?), Organic Expansion Path (how does this niche connect to adjacent markets?), Capital Efficiency (high margins early, self-funded growth)\n- **Apply**: (1) Instead of looking for empty markets, look for small markets where premium customers are underserved → (2) Verify structural advantage: why can you serve this niche better than anyone else? → (3) Enter with a premium offering: charge high, serve few, learn fast → (4) Use early margins to fund expansion into adjacent niches → (5) Never try to go mass-market before the premium niche is dominant and profitable\n- **Key Q**: \"Where can I find the smallest premium niche where I have a structural advantage from day one?\"", "sha256": "3c8797613f49a8927a4c53ddcef499edd191ae486a9fc21b5ae90b7e33a8ba5d", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0029", "normalizedDefinition": "Seek a defensible space where a specific audience is underserved and the business can offer differentiated value economically.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Premium niches can create focus but do not automatically produce high margins or defensibility. Verify reachable demand, willingness to pay, delivery economics and competitive response." }, { "@id": "urn:business-engineer:source-entry:base:30", "@type": "SourceEntry", "id": "base:30", "sourceNumber": 30, "name": "Minimum Viable Audience (MVA)", "body": "The smallest group of people that can sustain a business — not the largest addressable market, but the tightest cluster of humans whose problem is urgent enough that they will pay, stay, and advocate. The MVA is found not by imagining new markets but by zooming into existing ones to find pockets of unmet need. An MVA of 100 passionate users beats an addressable market of 10 million indifferent ones, because feedback loops are faster, loyalty is deeper, and iteration is cheaper.\n- **Components**: Audience Precision (demographic, psychographic, and behavioral specificity), Urgency Test (is the problem urgent enough to drive purchase without persuasion?), Sustainability Test (can this group generate enough revenue to sustain the business?), Feedback Density (is the audience accessible enough for rapid iteration?)\n- **Apply**: (1) Start with an existing market, not a hypothetical one → (2) Zoom in: who within this market has the most urgent, specific, underserved problem? → (3) Define the MVA: the smallest group whose urgency, willingness to pay, and accessibility are all high → (4) Test: can this group sustain the business at premium pricing? → (5) Serve them with obsessive focus until they become advocates → (6) Let the MVA define the product, not the other way around\n- **Key Q**: \"Who are the fewest people who need this most urgently — and can they sustain the business?\"", "sha256": "2f023137f4a881b065d4579bd8c0a5c0ba8c2ae8ebac69374643086faee7f207", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0030", "normalizedDefinition": "Start with the smallest audience that can sustain useful learning and a viable economic wedge.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:31", "@type": "SourceEntry", "id": "base:31", "sourceNumber": 31, "name": "Niche-to-Microniche Strategy", "body": "The practice of targeting the smallest coherent market segment — not just a niche, but a microniche — to trigger fast feedback loops and early proof of value. A microniche is a segment so specific that you can serve every member personally, learn their constraints intimately, and iterate faster than any competitor targeting a broader audience. The microniche is not the destination; it is the launchpad.\n- **Components**: Microniche Definition (the smallest coherent segment with a shared, specific problem), Feedback Loop Speed (how quickly can you learn from this group?), Proof of Value (can you demonstrate undeniable results for this segment?), Launchpad Potential (does mastering this microniche unlock adjacent segments?)\n- **Apply**: (1) Take your niche and ask: can I make this smaller and more specific? → (2) Define the microniche: a group so tight you can know every member by name → (3) Enter with a hyper-specific offer tailored to their exact problem → (4) Maximize feedback loop speed: talk to every user, iterate daily → (5) Achieve proof of value: measurable results that are undeniable → (6) Use the proof of value to expand to adjacent microniches\n- **Key Q**: \"Is my target segment small enough for fast feedback and proof of value — or too broad for either?\"", "sha256": "26bd543a87578530b878c4a5ecb0ff1d6df0d42a5a4fa7f7df503ed34c7ed0f1", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0031", "normalizedDefinition": "Narrow a market to a group with a shared problem, reachable distribution and a specific reason to choose the offer.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:32", "@type": "SourceEntry", "id": "base:32", "sourceNumber": 32, "name": "Adjacent Niche Expansion", "body": "The systematic method for entering neighboring market segments using existing know-how, brand credibility, and infrastructure. Adjacent expansion is not random diversification — it follows a logic of proximity: the next niche shares enough characteristics with the current one that your competitive advantage transfers, but is different enough to represent genuine growth. Each expansion should feel like a natural extension, not a leap of faith.\n- **Components**: Proximity Mapping (which niches share enough DNA with the current one?), Advantage Transfer Test (does our competitive edge carry over?), Infrastructure Leverage (can we serve the new niche with existing systems?), Brand Permission (does the market believe we belong here?)\n- **Apply**: (1) Map all segments adjacent to your current niche → (2) For each, test proximity: does our core advantage transfer? → (3) Test infrastructure leverage: can we serve this segment without major new investment? → (4) Test brand permission: does our reputation in the current niche give us credibility here? → (5) Prioritize the adjacent niche that scores highest on all three → (6) Enter with a tailored offer, not a copy of the current one → (7) Repeat the cycle from each new niche\n- **Key Q**: \"Which adjacent niche can I enter where my existing advantage, infrastructure, and brand credibility transfer most naturally?\"", "sha256": "4a6af186cb67432d2ef80c96eb8eef1fae902b2594ab280de9f96a112d282f3d", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0032", "normalizedDefinition": "Expand into an adjacent audience when transferable capabilities and distribution outweigh the additional complexity.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:33", "@type": "SourceEntry", "id": "base:33", "sourceNumber": 33, "name": "Transitional Business Model", "body": "The recognition that business models must transform at each growth stage — the model that got you from 0 to 1 will not get you from 1 to 10, and the model for 1 to 10 will not get you from 10 to 100. At each stage, not only the business model but also the mindset and organizational design must transform. The transitional model is not a failure of the original model; it is a feature of growth. Leaders who cling to the original model past its usefulness become the constraint.\n- **Components**: Stage Recognition (what growth stage are you in — 0→1, 1→10, 10→100?), Model Fitness (is the current model still fit for the current stage?), Transformation Triggers (what signals indicate the model must change?), Mindset Shift (how must the leadership mindset evolve?), Org Design Shift (how must the organizational structure change?)\n- **Apply**: (1) Honestly assess your current growth stage → (2) Evaluate model fitness: is the current model generating increasing or decreasing returns? → (3) Watch for transformation triggers: plateauing growth, increasing friction, talent misalignment → (4) When triggers appear, redesign the business model for the next stage → (5) Simultaneously evolve mindset (from founder to CEO to architect) and org design (from flat to layered to networked) → (6) Expect this transformation to be uncomfortable — it means the system is working\n- **Key Q**: \"Is my current business model still fit for this growth stage — or am I clinging to the model that got me here?\"", "sha256": "2264352990d5f4c08990e02ec81770758dc11412bd94890a98f3afec4f950ae0", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0033", "normalizedDefinition": "Use a temporary business model to acquire resources or learning for a more durable model, with explicit transition conditions.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Business-model changes may be needed at growth transitions; they are not mandatory at numerical 0-to-1, 1-to-10 or 10-to-100 boundaries. Diagnose actual model fit." }, { "@id": "urn:business-engineer:source-entry:base:34", "@type": "SourceEntry", "id": "base:34", "sourceNumber": 34, "name": "Business Scaling Framework", "body": "The alignment framework for scaling: product, business model, and organizational design must all be aligned to serve progressively wider market segments. If the product scales but the business model does not, margins collapse. If the business model scales but the org design does not, execution fails. Scaling is not doing more of the same — it is a coordinated transformation across all three dimensions simultaneously.\n- **Components**: Product Scaling (does the product serve wider segments without degrading quality?), Business Model Scaling (do unit economics improve or at least hold with volume?), Org Design Scaling (can the organization execute at higher volume without chaos?), Alignment Check (are all three dimensions scaling in sync?)\n- **Apply**: (1) Assess product: can it serve the next wider segment without custom work or quality degradation? → (2) Assess business model: do unit economics improve with scale, or do hidden costs emerge? → (3) Assess org design: can the team execute at 10x volume without breaking? → (4) Identify the lagging dimension — the one that cannot keep up → (5) Fix the lagging dimension before attempting to scale further → (6) Scale only when all three dimensions are aligned\n- **Key Q**: \"Are my product, business model, and org design all aligned for the next stage of scale — or is one lagging?\"", "sha256": "e55e03917dcce060c48448ed56fccd949b738cabd2bca1e7d1f3ff86ad3f0dca", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0034", "normalizedDefinition": "Expand demand and operating capacity while monitoring unit economics, coordination costs and service quality.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:35", "@type": "SourceEntry", "id": "base:35", "sourceNumber": 35, "name": "Scalability Matrix", "body": "A 2x2 matrix that plots Cost of Error (high/low) against Feedback Loop Type (fast/slow) to determine the optimal scaling approach: Optimal (low error cost + fast feedback = scale aggressively), Constrained (low error cost + slow feedback = scale carefully with patience), Controlled (high error cost + fast feedback = scale with guardrails), and Non-Scalable (high error cost + slow feedback = do not attempt rapid scaling). This matrix prevents the common mistake of applying one-size-fits-all scaling logic to businesses with fundamentally different risk/feedback profiles.\n- **Components**: Optimal Quadrant (low error cost + fast feedback → scale aggressively, iterate fast), Constrained Quadrant (low error cost + slow feedback → scale patiently, await results), Controlled Quadrant (high error cost + fast feedback → scale with safety systems, monitor closely), Non-Scalable Quadrant (high error cost + slow feedback → do not force scale, focus on quality)\n- **Apply**: (1) Assess your business: what is the cost of an error at scale? → (2) Assess feedback loop speed: how quickly do you learn if something went wrong? → (3) Plot your position on the matrix → (4) If Optimal: pour fuel on the fire → If Constrained: scale but be patient → If Controlled: scale with guardrails → If Non-Scalable: stop trying to force scale and compete on quality → (5) Reassess as the business evolves — quadrant position can shift\n- **Key Q**: \"What is my real error cost and feedback speed — and is my scaling approach appropriate for that combination?\"", "sha256": "3d01ebd0dc3bff33116857dfb07d9e3b2efe122f19b3d3b7cc5e99534219fe6f", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0035", "normalizedDefinition": "Compare growth opportunities by their demand potential and the operating constraints that determine scalable delivery.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "High error cost and slow feedback make rapid scaling difficult, not inherently impossible. Assess process redesign, instrumentation, controls and the benefits of controlled scale." }, { "@id": "urn:business-engineer:source-entry:base:36", "@type": "SourceEntry", "id": "base:36", "sourceNumber": 36, "name": "Fractal Market Expansion", "body": "The observation that market dynamics repeat at different scales — a pattern that works for a microniche will often repeat at the niche level, the segment level, and the market level — but the dynamics change with scale. Smaller scales are more controllable, faster to iterate on, and easier to dominate. The fractal insight is that you can test your strategy at micro scale and, if the pattern holds, expand with confidence — but you must adapt execution to each scale's unique dynamics.\n- **Components**: Pattern Identification (what works at the micro level?), Scale Testing (does the pattern repeat at the next level up?), Dynamic Adaptation (how do dynamics change with scale — speed, competition, capital requirements?), Controlled Expansion (expand one scale level at a time, validating pattern persistence)\n- **Apply**: (1) Identify the pattern that drives success at your current micro level → (2) Hypothesize: will this pattern repeat at the next scale? → (3) Test at the next scale with controlled expansion → (4) Observe: does the pattern hold, or do new dynamics emerge? → (5) Adapt execution for the new scale's unique characteristics → (6) Repeat: expand one level at a time, validating pattern persistence at each step\n- **Key Q**: \"Does my winning pattern repeat at the next scale — and what dynamics change as I grow?\"", "sha256": "9cce67b9abb7999d1625851ea0c42594bac721d3b1e212fad6e2215b6a27bf1e", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0036", "normalizedDefinition": "Replicate a working market pattern across smaller or adjacent units while testing which contextual differences break replication.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:37", "@type": "SourceEntry", "id": "base:37", "sourceNumber": 37, "name": "Speed-Reversibility Matrix", "body": "A decision framework with four quadrants defined by Impact (high/low) and Reversibility (easy/hard to undo): Strategic Deliberation (high impact + hard to reverse — take your time, get it right), Smart Experimentation (high impact + easy to reverse — move fast, learn from outcomes), Careful Consideration (low impact + hard to reverse — don't rush on principle), and Rapid Iteration (low impact + easy to reverse — just do it, iterate, don't overthink). This matrix prevents both decision paralysis (treating everything as irreversible) and recklessness (treating everything as low-impact).\n- **Components**: Strategic Deliberation (high impact + low reversibility → slow down, analyze deeply, consult widely), Smart Experimentation (high impact + high reversibility → move quickly, learn from outcomes, adjust), Careful Consideration (low impact + low reversibility → apply appropriate diligence), Rapid Iteration (low impact + high reversibility → execute immediately, iterate from results)\n- **Apply**: (1) For any pending decision, assess: how high is the impact if this goes wrong? → (2) Assess: how easily can this be reversed or corrected? → (3) Plot the decision on the matrix → (4) Match your decision speed and rigor to the quadrant → (5) The most common errors: treating reversible decisions as irreversible (paralysis), and treating irreversible decisions as reversible (recklessness) → (6) Review: are you consistently in the right quadrant for each decision type?\n- **Key Q**: \"Is this decision high-impact and irreversible (deliberate) — or low-impact and reversible (just do it)?\"", "sha256": "37a412c7c0a5b59373680c24f9e4fc850d86261f2049ab5229938ea3c80d286e", "sourceCategory": "IV. MARKET ENTRY & SCALING", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0037", "normalizedDefinition": "Choose an action's speed and commitment according to reversibility, learning value, downside and the cost of delay.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:38", "@type": "SourceEntry", "id": "base:38", "sourceNumber": 38, "name": "Moat Hierarchy (Level 1/2/3)", "body": "A three-tier classification of competitive moats based on durability and compounding power. Level 1 moats are static advantages (brand, scale, patents) — real but erodible. Level 2 moats are dynamic advantages (network effects, ecosystem lock-in) — stronger but still attackable. Level 3 moats are compounding interaction advantages — those that get stronger with every user interaction, creating a widening gap that competitors cannot close by copying. In the AI era, only Level 3 moats provide sustainable defense.\n- **Components**: Level 1 — Static Moats (brand recognition, scale economies, patents, regulatory capture — real but decaying without reinforcement), Level 2 — Dynamic Moats (network effects, switching costs, ecosystem lock-in — stronger but can be disrupted by paradigm shifts), Level 3 — Compounding Interaction Moats (every user interaction improves the product, trains the model, or deepens the data advantage — the moat widens automatically)\n- **Apply**: (1) Classify your current moats: are they Level 1, 2, or 3? → (2) Level 1 moats buy time but do not compound — use them to build higher levels → (3) Level 2 moats are strong but can be disrupted by platform shifts — monitor for paradigm changes → (4) Level 3 moats are the target: design systems where every user interaction makes the product better for all users → (5) If you lack Level 3, your long-term defensibility in AI is at risk → (6) Build from Level 1 → 2 → 3 sequentially\n- **Key Q**: \"Do my moats compound with every user interaction — or are they static and erodible?\"", "sha256": "83fa589fd1bd0b0483b1c746cc25398cafe600fddd910c5f237232042fe2fff9", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0038", "normalizedDefinition": "Classify sources of defensibility by their mechanism and durability, without assuming a universal ordering across markets.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Static, dynamic and interaction moats are analytical categories, not a universal durability ranking. Brand, scale, exclusive assets and regulatory position can remain durable. Compounding interaction moats are neither necessary nor automatically sufficient." }, { "@id": "urn:business-engineer:source-entry:base:39", "@type": "SourceEntry", "id": "base:39", "sourceNumber": 39, "name": "Five Defensible Moats in AI", "body": "The five moat types that provide real defense in the AI era: (1) Data Network Effects — more users generate more data, improving the product for everyone; (2) Community — engaged user communities that generate content, support, and switching costs; (3) Specialization Depth — domain expertise so deep it cannot be replicated by general-purpose models; (4) Workflow Lock-in — integration into user workflows so deep that switching costs are prohibitive; (5) Enterprise Relationships — trust-based relationships with large organizations that take years to build. Each moat type has different build times, capital requirements, and vulnerability profiles.\n- **Components**: Data Network Effects (usage → data → model improvement → more usage), Community (user-generated content, peer support, identity, switching costs), Specialization Depth (domain expertise, vertical data, custom models), Workflow Lock-in (deep integration into daily operations, high switching cost), Enterprise Relationships (trust, compliance, multi-year contracts, relationship depth)\n- **Apply**: (1) Assess which of the five moats your business can realistically build → (2) Match to your current capabilities: data-rich companies start with data network effects; domain experts start with specialization depth → (3) Build one moat to critical mass before layering a second → (4) Monitor vulnerability: data moats are vulnerable to synthetic data; community moats are vulnerable to platform shifts → (5) The strongest position layers 2-3 moats that reinforce each other\n- **Key Q**: \"Which of the five AI moats am I building — and is it the right one for my capabilities?\"", "sha256": "32cff03437def348ea27339299670423009902c52ef6ef9ec310dc1a4cb82406", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0039", "normalizedDefinition": "Assess AI defensibility through distinct sources of advantage such as distribution, proprietary inputs, integration and network effects; test each locally.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Treat the five types as a useful set, not an exhaustive list. Domain specialization and data scale can be replicated; test exclusivity, learning value, substitutes, retention and economics." }, { "@id": "urn:business-engineer:source-entry:base:40", "@type": "SourceEntry", "id": "base:40", "sourceNumber": 40, "name": "Compound Moat Strategy", "body": "The principle that the strongest competitive positions are built by layering moats sequentially — starting with one moat matched to current capabilities, establishing its flywheel, and then adding a second adjacent moat once the first is spinning. The compound effect makes the combination far stronger than either moat alone. The key insight: do not try to build multiple moats simultaneously from scratch; each moat requires focused investment to reach critical mass.\n- **Components**: Primary Moat Selection (which moat matches current capabilities best?), Flywheel Establishment (has the primary moat reached self-reinforcing critical mass?), Adjacent Moat Selection (which second moat is most naturally reinforced by the first?), Compound Effect (how does the combination create defense greater than the sum?)\n- **Apply**: (1) Assess your capabilities: what moat can you build fastest? → (2) Invest concentrated resources to establish that moat's flywheel → (3) Test for flywheel: is the moat self-reinforcing? Are you gaining strength without proportional effort? → (4) Once the first flywheel spins, select the adjacent moat that the first most naturally supports → (5) Build the second moat using the advantages from the first → (6) The compound of two spinning flywheels creates a defensible position that's exponentially harder to attack\n- **Key Q**: \"Is my first moat's flywheel spinning before I try to build a second — or am I diluting investment across multiple unproven moats?\"", "sha256": "08054ce87e0eb1491ea527c3596d0343943f4370963d47325b4af230f0cb1320", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0040", "normalizedDefinition": "Reinforcing advantages can compound when one moat finances, strengthens or protects another; demonstrate the link rather than counting labels.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Sequential moat building is a resource-allocation heuristic. Some complements must be developed together; compounded advantage is not necessarily exponential." }, { "@id": "urn:business-engineer:source-entry:base:41", "@type": "SourceEntry", "id": "base:41", "sourceNumber": 41, "name": "The Survival Test", "body": "The ultimate competitive litmus test: \"If Google/Microsoft/OpenAI copied your product tomorrow with unlimited resources, would users stay?\" If the answer is no, you do not have a moat — you have a feature that will be absorbed by a platform. If the answer is yes, you need to identify exactly why users would stay (data, community, workflow integration, specialization, trust) and double down on those specific factors. This test is deliberately harsh because the AI landscape is consolidating rapidly.\n- **Components**: Copy Scenario (the largest, best-resourced competitor replicates your core offering), User Retention Analysis (would users stay, and why specifically?), Moat Identification (what exactly prevents defection — data, community, workflow lock-in, specialization, relationships?), Vulnerability Assessment (how long before the copy erodes your advantage?)\n- **Apply**: (1) Imagine the worst case: the strongest possible competitor copies your product with unlimited resources → (2) Honestly assess: would your users stay? → (3) If no: you are building a feature, not a business — pivot to moat building immediately → (4) If yes: identify the specific reasons (data advantage? community? workflow lock-in? trust?) → (5) Double down investment on those specific retention factors → (6) Re-run this test quarterly as the competitive landscape shifts\n- **Key Q**: \"If the most powerful competitor copied us tomorrow, would our users stay — and what specifically would keep them?\"", "sha256": "b6bf00b1ab738696f7c4d8f98d3f3a16de4db094d684ed2d8283522627fbd45b", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0041", "normalizedDefinition": "Stress a business under adverse competition, funding or technology changes to identify what sustains it and what would make it fail.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Use a plausible funded competitor response and a realistic time horizon. Failure against an unlimited-resource hypothetical does not prove that a viable niche business is only a feature." }, { "@id": "urn:business-engineer:source-entry:base:42", "@type": "SourceEntry", "id": "base:42", "sourceNumber": 42, "name": "Three Layers of AI Industry", "body": "A structural model that maps the AI industry into three strategic layers: (1) Foundational Layer — general-purpose AI engines (OpenAI, Anthropic, Google DeepMind) competing on model capability; (2) Middle Layer — specialized vertical AI companies that apply foundation models to specific industries with deep domain data; (3) Application Layer — user-facing products that compete on UX, network effects, and distribution. Each layer has different competitive dynamics, moat types, and capital requirements. Companies must choose their layer or risk being stuck between layers with no clear advantage.\n- **Components**: Foundational Layer (general AI engines — competition is on model capability, capital intensity is extreme), Middle Layer (vertical AI specialization — competition is on domain data and expertise), Application Layer (user-facing products — competition is on UX, network effects, distribution, brand)\n- **Apply**: (1) Identify which layer your company competes in → (2) Assess: are you optimally positioned for that layer's competitive dynamics? → (3) Foundational: do you have the capital and talent for model development? → Middle: do you have deep domain data and expertise? → Application: do you have superior UX, distribution, or network effects? → (4) If stuck between layers (no clear advantage at any), either commit to one layer or find a unique cross-layer position → (5) Monitor layer dynamics: foundational is consolidating, middle is fragmenting, application is where network effects matter most\n- **Key Q**: \"Which layer of the AI industry am I competing in — and do I have the right assets for that layer's competitive dynamics?\"", "sha256": "ff6104ead47520554c93aab257c17cc6f42853dc1d4c9298a793a50f395814ac", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0042", "normalizedDefinition": "Separate functional layers of an AI industry to locate dependencies, economics and value capture; layer boundaries depend on the question.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The three-layer map is a high-level lens, not an exhaustive AI stack. Locate cross-layer positions and use more granular layers when infrastructure, orchestration or governance matters." }, { "@id": "urn:business-engineer:source-entry:base:43", "@type": "SourceEntry", "id": "base:43", "sourceNumber": 43, "name": "Tech Moat → Market Power Translation", "body": "The framework for understanding how technical capabilities convert into actual market power — because a technical moat alone does not guarantee market dominance. The translation happens through three channels: Efficiency (the tech makes you faster/cheaper), Distribution (the tech enables superior reach), and Brand (the tech creates a perception of superiority). A technical advantage that fails to translate through at least one channel will be structurally undervalued.\n- **Components**: Technical Capability (the raw technological advantage), Efficiency Channel (does the tech make operations faster, cheaper, or more scalable?), Distribution Channel (does the tech enable superior reach, access, or discovery?), Brand Channel (does the tech create a perception of quality, innovation, or trust?), Market Power (the resulting competitive position from successful translation)\n- **Apply**: (1) Inventory your technical capabilities → (2) For each, test the three translation channels: does this tech make us more efficient? Does it improve distribution? Does it enhance brand perception? → (3) If a capability doesn't translate through any channel, it is intellectually interesting but commercially irrelevant → (4) Invest in the channel that provides the strongest translation → (5) The goal is not the best technology but the best translation of technology into market power\n- **Key Q**: \"Is my technical advantage actually translating into market power — or is it just technically impressive?\"", "sha256": "2612a26edef52e36b34c8040ac38b5cf2e8ba73388952877fc25cdbe9eaf1431", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0043", "normalizedDefinition": "A technical advantage becomes market power only through mechanisms such as distribution, switching costs, scarcity or institutional control.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:44", "@type": "SourceEntry", "id": "base:44", "sourceNumber": 44, "name": "Value Translation Space", "body": "The bridge between technical moat and market impact, identifying the four dimensions through which technology creates actual user and market value: User Experience (how the technology feels to use), Network Effects (how it improves with more users), Brand (what it signals about the user or company), and Distribution Power (how it reaches and retains users). This space is where many technically superior products fail — they build the moat but never cross the bridge to market value.\n- **Components**: User Experience (intuitive, delightful, friction-free interaction with the technology), Network Effects (each additional user increases value for all existing users), Brand (the market's perception of quality, trust, and identity associated with the product), Distribution Power (the ability to reach, acquire, and retain users efficiently)\n- **Apply**: (1) Assess your technical moat: what is the underlying technology advantage? → (2) Map across all four value translation dimensions: where is the tech creating value? → (3) Identify the strongest dimension — lean into it → (4) Identify the weakest dimension — fix it or accept the limitation → (5) The most successful companies have at least two strong value translation dimensions → (6) If none are strong, the technical moat will be commoditized regardless of its sophistication\n- **Key Q**: \"Through which dimensions is my technology actually creating market value — and which dimensions am I neglecting?\"", "sha256": "5fc202c715a4bffa4a4ae839aec4d97ac58a7d191539e7ba5303a9b2de31a3e2", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0044", "normalizedDefinition": "Identify the gap between a capability and a customer outcome, then determine what integration or business design translates one into the other.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:45", "@type": "SourceEntry", "id": "base:45", "sourceNumber": 45, "name": "Three AI Strategic Archetypes", "body": "Three distinctive positions in the AI landscape: (1) Full-Stack Integrators — companies that control the entire stack from model to product to user (like OpenAI's trajectory); (2) Specialized Dominators — companies that own a specific vertical or capability with such depth that generalists cannot compete (like Bloomberg's AI for finance); (3) Strategic Enablers — companies that build the picks-and-shovels infrastructure enabling others (like NVIDIA, cloud providers). Each archetype has different capital requirements, risk profiles, and defensibility. Companies must choose one — trying to be all three is the most common strategic error.\n- **Components**: Full-Stack Integrators (control model + product + distribution — highest capital requirement, highest potential market power), Specialized Dominators (own a vertical with deep data + expertise — moderate capital, high defensibility in niche), Strategic Enablers (provide infrastructure/tools for others — lower risk, recurring revenue, dependent on ecosystem health)\n- **Apply**: (1) Assess your resources, capabilities, and ambition → (2) Full-Stack requires enormous capital, talent, and distribution — only viable for well-funded entities → (3) Specialized Dominator requires deep domain expertise and proprietary data — best for vertical experts → (4) Strategic Enabler requires platform thinking and ecosystem cultivation — best for infrastructure builders → (5) Choose one archetype and align all resources → (6) The danger zone is between archetypes — committed to none, optimized for none\n- **Key Q**: \"Am I a Full-Stack Integrator, a Specialized Dominator, or a Strategic Enabler — and is my resource allocation aligned with that choice?\"", "sha256": "4cd3d7ff76da977b23cf4ca9d1922989faf571dc73b7e333cdd6a40c40e78641", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0045", "normalizedDefinition": "Compare AI strategic positions by the resources, control and economics their chosen role requires; archetypes can overlap or change.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Archetypes describe strategic emphasis. Firms may combine roles when complementary assets and resources support it; forced exclusivity can obscure a viable position." }, { "@id": "urn:business-engineer:source-entry:base:46", "@type": "SourceEntry", "id": "base:46", "sourceNumber": 46, "name": "Weak Spot Analysis (5 Attack Vectors)", "body": "A systematic framework for identifying where established players are most exposed to disruption, using five attack vectors: (1) Low-End Disruption — serve the overserved bottom of the market with simpler, cheaper offerings; (2) Business Model Innovation — attack the same market with a fundamentally different economic model; (3) New Technology Platform — ride a technology shift that resets competitive advantages; (4) Niche Focus — serve a specific segment so well that the generalist cannot respond; (5) Adjacent Market Entry — enter from a neighboring market where you already have credibility and infrastructure.\n- **Components**: Low-End Disruption (simpler, cheaper for the overserved), Business Model Innovation (different economic model for the same market), New Tech Platform (technology shift that resets advantages), Niche Focus (serve one segment better than any generalist can), Adjacent Market Entry (enter from a neighboring market with existing credibility)\n- **Apply**: (1) Select the incumbent you want to challenge → (2) Evaluate all five vectors: where is the incumbent weakest? → (3) Low-end: are they over-serving and over-charging the bottom of the market? → (4) Business model: could a different margin structure undercut them? → (5) New platform: is a technology shift resetting their advantages? → (6) Niche focus: is there a segment they ignore or underserve? → (7) Adjacent entry: can you enter from a market where you're already strong? → (8) Choose the vector where you have the strongest structural advantage\n- **Key Q**: \"Through which attack vector is this incumbent most vulnerable — and where do I have the strongest advantage to exploit it?\"", "sha256": "1c2bcf6499d2b93b97ca74865471fa00fd4c6a913e6890f4791c810d929d0f01", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0046", "normalizedDefinition": "Identify a rival's consequential weakness and test whether exploiting it is feasible, valuable and defensible.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:47", "@type": "SourceEntry", "id": "base:47", "sourceNumber": 47, "name": "Margin Conflict Strategy", "body": "The deliberate design of business models that operate at different margin structures than incumbents, forcing them to choose between responding (and cannibalizing their own high-margin business) or ignoring you (and ceding the market). This is one of the most powerful competitive weapons because it exploits the incumbent's organizational incentives against them — the sales team, the board, the investors all resist margin erosion, creating an internal conflict that slows response.\n- **Components**: Incumbent Margin Analysis (what margins does the competitor need to satisfy their stakeholders?), Alternative Margin Design (how can you build a profitable model at lower/different margins?), Cannibalization Dilemma (responding means destroying their own margins), Response Delay (the internal conflict that slows incumbent adaptation)\n- **Apply**: (1) Analyze the incumbent's margin structure: what do they charge and why? → (2) Design a model that is profitable at a margin structure the incumbent cannot match without cannibalization → (3) Enter the market: the incumbent now faces a dilemma — respond and erode margins, or ignore and lose share → (4) The internal conflict (sales teams resist margin cuts, boards resist revenue decline) creates a response delay → (5) Use that delay to build your moat → (6) By the time they respond, you should have a structural advantage\n- **Key Q**: \"Can I design a model that's profitable at margins the incumbent can't match without cannibalizing themselves?\"", "sha256": "eb90b95798176d2246bf9215cf58c43ff2d5688d46e18fe06919f76067fe93d4", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0047", "normalizedDefinition": "An incumbent may hesitate to adopt an approach that undermines its existing margin structure; test whether adaptation or segmentation resolves the conflict.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:48", "@type": "SourceEntry", "id": "base:48", "sourceNumber": 48, "name": "Strategic Mismatch Model", "body": "The insight that disruptors win not by having better data than incumbents but by having a better perspective on what data matters. The strategic mismatch is not about quantity or quality of resources — it is about interpretation. Incumbents are optimized to see the world through their existing lens; disruptors bring a different lens that reveals opportunities the incumbent's lens is structurally blind to. The battle is won in the interpretation layer, not the data layer.\n- **Components**: Incumbent Lens (how does the established player interpret market signals?), Disruptor Lens (what different interpretation framework reveals unseen opportunities?), Interpretation Gap (the delta between what both see in the same data), Structural Blindness (what the incumbent's lens systematically prevents them from seeing)\n- **Apply**: (1) Map the incumbent's interpretive lens: what do they optimize for? How do they measure success? → (2) Identify their structural blindness: what does their lens systematically filter out? → (3) Develop an alternative interpretation: using the same data, what do you see that they can't? → (4) Build your strategy around the interpretation gap → (5) The incumbent may have more data, more resources, and more talent — but if your interpretation is more accurate, you will outmaneuver them → (6) The mismatch persists as long as the incumbent's incentives keep their lens locked\n- **Key Q**: \"Do I see something in the data that the incumbent's lens structurally prevents them from seeing?\"", "sha256": "13a7abbbbfb0dd949cdc6ac2c83e5b6edc18161e87d655240583690513641361", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0048", "normalizedDefinition": "Look for a mismatch between an organization's strategy, capabilities, incentives and changing market requirements.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Interpretation can matter, but superior data, execution and resources can also decide outcomes. Treat perspective advantage as one mechanism to test." }, { "@id": "urn:business-engineer:source-entry:base:49", "@type": "SourceEntry", "id": "base:49", "sourceNumber": 49, "name": "Non-Linear Competition", "body": "The recognition that competitive dynamics do not follow predictable, linear patterns — asymmetric advantages compound unpredictably, creating sudden shifts that traditional competitive analysis cannot forecast. A small advantage in one dimension (data, distribution, brand, workflow lock-in) can suddenly cascade into dominance when it crosses an invisible threshold. This means competitive strategy must account for non-linear jumps, not just incremental positioning.\n- **Components**: Asymmetric Advantage Identification (where do you have a small advantage with compounding potential?), Threshold Detection (at what point does the advantage cascade into dominance?), Non-Linear Sensitivity (small changes in input can produce large changes in outcome), Incumbent Blind Spot (linear thinkers underestimate non-linear competitors)\n- **Apply**: (1) Identify your asymmetric advantages — areas where you have even a small edge → (2) Assess compounding potential: does this advantage grow with each iteration, user, or transaction? → (3) Estimate the threshold: at what point does incremental growth become a cascade? → (4) Invest to reach the threshold before competitors recognize the threat → (5) Defend the compounding mechanism once the cascade begins → (6) Do not expect competitors to see this coming — linear thinkers systematically underestimate non-linear dynamics\n- **Key Q**: \"Do I have an asymmetric advantage that could compound non-linearly — and am I investing to reach the cascade threshold?\"", "sha256": "02d7fd09f059aeadc32b35ed675eb2b72135fd0a6a0328db42042343fa835ad7", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0049", "normalizedDefinition": "Competition can change discontinuously when technology, distribution or business-model shifts alter the basis of advantage.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:50", "@type": "SourceEntry", "id": "base:50", "sourceNumber": 50, "name": "Winner-Take-All Effects", "body": "The structural analysis of how lock-in effects — network effects, switching costs, and data advantages — consolidate AI markets around a dominant player in each layer. Not all markets have winner-take-all dynamics; the framework identifies which conditions create them (high network effects, high switching costs, high data returns to scale) and what it means strategically: in WTA markets, second place is a losing position, and the strategic imperative is either to win or to redefine the market layer.\n- **Components**: Network Effect Strength (how much does each user increase value for others?), Switching Cost Height (how difficult is it for users to leave?), Data Returns to Scale (does more data create proportionally better products?), Consolidation Trajectory (is the market converging toward one winner or remaining fragmented?), Strategic Implication (if WTA, either win or redefine the layer)\n- **Apply**: (1) Assess the market for WTA conditions: strong network effects? High switching costs? Data returns to scale? → (2) If all three are present, this is a WTA market — half measures will fail → (3) If you're the leader: invest aggressively to widen the gap → (4) If you're not the leader: either find a way to leapfrog (technology shift, redefine the layer) or exit → (5) If WTA conditions are weak, the market supports multiple players — compete on differentiation → (6) Monitor: WTA conditions can emerge or dissolve as technology and regulation evolve\n- **Key Q**: \"Is this a winner-take-all market — and if so, am I positioned to win or do I need to redefine the game?\"", "sha256": "41834a9b101472e936fc740ef568dd74fe1125467f1a02664f17bd7b6cd377dc", "sourceCategory": "V. COMPETITIVE STRATEGY & MOATS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0050", "normalizedDefinition": "Positive feedback and market structure may concentrate outcomes; congestion, differentiation, multi-homing and regulation can limit concentration.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Test winner-take-most versus winner-take-all conditions, including multi-homing, differentiation, congestion, regulation and declining returns. Second place can remain profitable." }, { "@id": "urn:business-engineer:source-entry:base:51", "@type": "SourceEntry", "id": "base:51", "sourceNumber": 51, "name": "Agentic AI Four-Phase Moat Building", "body": "A sequential roadmap for building compounding advantages in the agentic AI space across four phases: (1) Foundation — build core agentic capabilities, establish basic reliability and trust; (2) Differentiation — develop unique capabilities competitors cannot easily replicate; (3) Dominance — achieve flywheel effects where usage compounds advantage automatically; (4) Expansion — extend the moat into adjacent domains using the compounding base. Each phase must be substantially complete before advancing to the next — skipping phases creates fragile positions.\n- **Components**: Foundation Phase (core agentic capabilities, reliability, basic trust), Differentiation Phase (unique capabilities, proprietary data, specialized workflows), Dominance Phase (self-reinforcing flywheels, compounding advantage), Expansion Phase (adjacent domain entry, moat extension, ecosystem building)\n- **Apply**: (1) Honestly assess: which phase are you in? Most overestimate → (2) Foundation: focus on reliability, speed, and basic trust — do not differentiate yet → (3) Differentiation: invest in what makes you unique — proprietary data, specialized capabilities, unique workflows → (4) Dominance: design systems so usage compounds advantage — data flywheels, network effects, workflow lock-in → (5) Expansion: once the flywheel spins, extend into adjacent domains → (6) Do not skip phases — the foundation must hold the weight of everything built above it\n- **Key Q**: \"Which phase am I actually in — and am I doing the work required at this phase before trying to jump ahead?\"", "sha256": "2e4268d5e4278806ca3aa9c23ac7548177ee570575181fec35134ec61ce11721", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0051", "normalizedDefinition": "Analyze how agentic AI defensibility changes as capabilities and adoption develop; phase labels are a scenario framework, not a fixed chronology.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The four phases are a planning heuristic, not a required historical sequence. Phases can overlap or reverse and should be diagnosed from evidence." }, { "@id": "urn:business-engineer:source-entry:base:52", "@type": "SourceEntry", "id": "base:52", "sourceNumber": 52, "name": "Three Kingdoms of Agentic AI", "body": "Three fundamentally different market territories for agentic AI, each with distinct moat strategies, go-to-market approaches, and success metrics: (1) Consumer Kingdom — competition is for attention, moat is habit and network effects, metric is engagement; (2) B2B Kingdom — competition is for ROI validation, moat is workflow integration and measurable outcomes, metric is value delivered; (3) Enterprise Kingdom — competition is for trust, moat is compliance, security, and relationship depth, metric is contract duration and expansion. Each kingdom has its own rules; strategies that work in one often fail in another.\n- **Components**: Consumer Kingdom (attention-based competition, habit/network moats, engagement metrics, viral distribution), B2B Kingdom (ROI-based competition, workflow/outcome moats, value metrics, sales-driven distribution), Enterprise Kingdom (trust-based competition, compliance/relationship moats, contract metrics, relationship-driven distribution)\n- **Apply**: (1) Identify which kingdom you are competing in — the rules differ fundamentally → (2) Consumer: invest in habit formation, viral loops, and attention capture → (3) B2B: invest in measurable ROI, workflow integration, and customer success → (4) Enterprise: invest in security, compliance, trust, and deep relationships → (5) Do not apply Consumer strategies in Enterprise (it signals naivety) or Enterprise strategies in Consumer (it kills speed) → (6) Some companies span kingdoms — but each kingdom needs its own approach\n- **Key Q**: \"Am I in the Consumer, B2B, or Enterprise kingdom — and does my strategy match that kingdom's rules?\"", "sha256": "9709c89c27d267b53893f7e58e95efe8dd689c45a25fb84d6446bec4b5d72574", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0052", "normalizedDefinition": "Map distinct agentic AI strategic arenas and their control points; boundaries and winners remain empirical questions.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:53", "@type": "SourceEntry", "id": "base:53", "sourceNumber": 53, "name": "Context Engineering", "body": "The science and practice of orchestrating, structuring, and prioritizing information to maximize AI model performance. Context engineering recognizes that the same model can produce dramatically different outputs depending on how context is constructed — what information is included, in what order, at what level of detail, with what framing. This is not prompt engineering (crafting individual queries) — it is the systematic architecture of the entire information environment the model operates within.\n- **Components**: Context Orchestration (selecting which information to include from available sources), Context Structuring (organizing information for optimal model processing), Context Prioritization (ordering information by relevance and importance), Context Maintenance (updating context as conditions change), Performance Measurement (tracking how context changes affect output quality)\n- **Apply**: (1) Map all available context sources for a given AI application → (2) Select: which information is most relevant and useful for the intended task? → (3) Structure: organize the selected information for optimal model comprehension → (4) Prioritize: order by relevance — most important context first → (5) Test: measure output quality with different context configurations → (6) Iterate: continuously refine context architecture based on performance data → (7) Remember: context engineering compounds — better context → better outputs → better data → better context\n- **Key Q**: \"Am I engineering the context my AI operates in — or just throwing information at it and hoping?\"", "sha256": "331cd5857d842f46b16ec33cbec08008556e459b4ced5aaf6e5aa66b2ffa77bf", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0053", "normalizedDefinition": "Engineer the information, tools, memory and instructions available to a system so that they support a defined task and reliable behavior.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:54", "@type": "SourceEntry", "id": "base:54", "sourceNumber": 54, "name": "Protocol Mastery", "body": "The principle that deep understanding and early adoption of AI protocol standards (such as the Model Context Protocol and its successors) creates ecosystem network effects and technical barriers to entry. Protocols are the invisible infrastructure that determines which AI systems can interoperate and which cannot. Companies that master protocols early become the connective tissue of the AI ecosystem, creating switching costs and network effects that are extremely difficult to replicate.\n- **Components**: Protocol Identification (which emerging standards will define AI interoperability?), Deep Implementation (not just adopting but mastering the protocol's capabilities and edge cases), Ecosystem Network Effects (each integration increases the value of your protocol mastery), Technical Barriers (protocol expertise creates switching costs for partners and customers), Standards Influence (contributing to protocol development shapes the rules in your favor)\n- **Apply**: (1) Identify the most consequential emerging AI protocols → (2) Invest in deep implementation — not surface adoption but mastery of capabilities and edge cases → (3) Build integrations that leverage protocol capabilities others haven't discovered → (4) Create ecosystem value: help partners implement the protocol, creating network effects around your expertise → (5) Contribute to protocol development to influence the standards → (6) The moat: as the ecosystem builds around your protocol mastery, switching costs compound\n- **Key Q**: \"Am I building deep protocol mastery that creates ecosystem lock-in — or treating protocols as commodity infrastructure?\"", "sha256": "d5dbc379278aab6ee96b0d124469a209f67507f630ef4db86c2162b708603d01", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0054", "normalizedDefinition": "Use protocols to improve coordination and interoperability while separating adoption, permission, portability and actual market control.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Open-protocol adoption enables interoperability but does not by itself establish lock-in or a moat. Verify scarce complements, ecosystem participation, governance, switching costs and demonstrated value; protocol availability is separate from business authorization." }, { "@id": "urn:business-engineer:source-entry:base:55", "@type": "SourceEntry", "id": "base:55", "sourceNumber": 55, "name": "Agentic Competitive Formula", "body": "A multiplicative formula for success in agentic AI: Success = Market Focus x Technical Excellence x Network Effects x Time. The critical insight is that this is a product, not a sum — if any factor is zero, the total is zero regardless of the others. A technically excellent product with no market focus fails. A focused product with no technical excellence fails. Perfect execution without time in market fails. All four factors must be non-zero and balanced.\n- **Components**: Market Focus (are you solving a specific, urgent problem for a defined audience?), Technical Excellence (is your technology genuinely superior in the ways that matter for that market?), Network Effects (does usage create compounding advantage?), Time (are you giving the compounding enough time to work?)\n- **Apply**: (1) Rate each factor honestly from 0 to 10 → (2) Multiply: if any factor is near zero, the product is near zero — fix that factor first → (3) Market Focus: narrow until you have a clearly defined audience with an urgent problem → (4) Technical Excellence: ensure superiority on the dimensions that matter to your market → (5) Network Effects: design for compounding — usage must improve the product → (6) Time: commit to the timeline required for compounding — impatience kills agentic businesses → (7) Balance all four — strength in three with zero in one is still zero\n- **Key Q**: \"Which factor in my competitive formula is closest to zero — and is that the one I'm investing in?\"", "sha256": "8316e24a224c017df9984dc3f6213317adaed27306e64cfb7d32ed695cfc8568", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0055", "normalizedDefinition": "Assess agentic competitiveness through complementary capabilities, integration, distribution and trust; illustrative formulas require measurement before calculation.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The multiplicative formula is a qualitative checklist, not a predictive equation. Network effects are not necessary for every successful business, and multiplying invented factor scores creates false precision." }, { "@id": "urn:business-engineer:source-entry:base:56", "@type": "SourceEntry", "id": "base:56", "sourceNumber": 56, "name": "AI-Up (AI-Native Startup)", "body": "The concept of the AI-native startup that iterates so rapidly — leveraging AI in every function from development to marketing to sales — that it can build a valuable company before incumbents can organize a response. The AI-Up is not a traditional startup using AI; it is a fundamentally new organizational form where AI augmentation is embedded in every process, enabling a small team to operate at the speed and scale of a much larger organization.\n- **Components**: AI-Native Operations (AI embedded in every function, not just the product), Speed Advantage (iteration cycles measured in hours/days, not weeks/months), Lean Team (small team with AI augmentation achieving enterprise-level output), Response Gap (the time between AI-Up's market entry and incumbent's organized response), Value Window (the period during which the AI-Up can build defensible value)\n- **Apply**: (1) Build every function — development, marketing, sales, support, analytics — with AI augmentation from day one → (2) Optimize for iteration speed: the AI-Up's primary advantage is speed of learning → (3) Maintain lean team size: AI augmentation should substitute for headcount → (4) Target the response gap: enter markets where incumbent response will be slow → (5) Build defensible value (moats, customers, data) before the response gap closes → (6) Never let organizational complexity outpace AI-augmented capacity\n- **Key Q**: \"Am I building an AI-native organization that can build defensible value before incumbents can respond — or a traditional startup using AI as a feature?\"", "sha256": "ded9f88edb4975f4a733ef1c4b59eff47de951b40f94f2461940878eb11ab811", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0056", "normalizedDefinition": "Redesign a workflow around feasible AI capabilities, its required outcomes and human responsibilities rather than adding automation without process change.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:57", "@type": "SourceEntry", "id": "base:57", "sourceNumber": 57, "name": "Platform Network Ecosystem", "body": "The framework for building multi-sided markets where the platform's value increases as more participants join each side. It requires cultivating network effects (more sellers attract more buyers attract more sellers), establishing platform governance (rules that balance openness with quality), and balancing control with participant value (extracting too much value kills the ecosystem, extracting too little kills the platform). The platform must serve as an enabling infrastructure, not a toll booth.\n- **Components**: Multi-Sided Market Design (what sides exist — producers, consumers, developers, advertisers?), Network Effect Cultivation (how does each side's growth attract the other sides?), Platform Governance (rules for quality, behavior, and value distribution), Control-Value Balance (how much does the platform extract vs. enable?), Ecosystem Health Metrics (participation growth, value creation, satisfaction across all sides)\n- **Apply**: (1) Define the sides of your market: who creates value, who consumes it, who enables it? → (2) Identify the chicken-and-egg problem: which side needs to be seeded first? → (3) Design for network effects: each participant's value must increase as others join → (4) Establish governance: rules that maintain quality without strangling participation → (5) Monitor the control-value balance: if participants feel extracted from rather than enabled, the ecosystem will decay → (6) Measure ecosystem health, not just platform revenue\n- **Key Q**: \"Does my platform enable more value than it extracts — and are network effects compounding across all sides?\"", "sha256": "2b183a14752404d9b11149972173ddea498e80afad3a6ff9d6ccbde6591b2aba", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0057", "normalizedDefinition": "Distinguish a platform's interfaces, a network's participants and an ecosystem's complementary relationships to explain value creation and capture.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:58", "@type": "SourceEntry", "id": "base:58", "sourceNumber": 58, "name": "Agentic Web Architecture", "body": "The emerging structural model for how AI agents will interact across the internet, comprising four layers: Agent Mesh Networks (how agents discover, communicate, and collaborate with each other), Decision Protocols (how agents make and coordinate decisions autonomously), Resource Allocation (how agents manage compute, data, and financial resources), and Autonomous Economic Systems (how agents conduct economic transactions and create value independently). This architecture represents the next evolution beyond the current web.\n- **Components**: Agent Mesh Networks (discovery, communication, and collaboration protocols between AI agents), Decision Protocols (frameworks for autonomous agent decision-making and coordination), Resource Allocation Systems (how agents manage and distribute compute, data, and financial resources), Autonomous Economic Systems (agent-to-agent transactions, value creation, and economic coordination)\n- **Apply**: (1) Map the current state of agentic web infrastructure: which layers are emerging? → (2) Identify which layer your company can contribute to or build on → (3) Agent Mesh: build or participate in agent discovery and communication networks → (4) Decision Protocols: develop or adopt frameworks for agent coordination → (5) Resource Allocation: create systems for efficient agent resource management → (6) Economic Systems: design mechanisms for agent-to-agent value exchange → (7) Position early: the architecture is being built now, and early participants will shape the standards\n- **Key Q**: \"Which layer of the agentic web architecture can I contribute to or build on — and am I positioning for the emerging infrastructure?\"", "sha256": "4911a67da401d4f8dd1fa38794f0eaf09230013032af64b7cf400bd26d3c1374", "sourceCategory": "VI. AGENTIC AI & PLATFORM STRATEGY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0058", "normalizedDefinition": "Map how agents discover, interpret, coordinate and act through web infrastructure, including the authority and controls at each interface.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Treat the architecture as a conceptual scenario. Current protocol support, agent autonomy and adoption require verification; do not describe an envisioned autonomous economy as an established state." }, { "@id": "urn:business-engineer:source-entry:base:59", "@type": "SourceEntry", "id": "base:59", "sourceNumber": 59, "name": "Amazon Flywheel", "body": "The canonical compounding growth loop: lower prices attract more customers, more customers attract more third-party sellers, more sellers create greater selection, greater selection and competition drive costs lower, lower costs enable even lower prices. This flywheel has been compounding for decades because each element reinforces every other element, making it structurally impossible to compete with any single element in isolation. The lesson is not about Amazon — it is about designing business systems where growth compounds automatically.\n- **Components**: Lower Prices (attracts price-sensitive customers and increases volume), More Customers (attracts sellers and increases bargaining power), More Sellers (increases selection and competition), Greater Selection (improves customer experience), Lower Costs (scale and competition drive efficiency), Reinforcement Loop (each element strengthens every other)\n- **Apply**: (1) Study the Amazon flywheel not to copy it but to understand the principle: every element must reinforce every other → (2) Map your own business: what is the equivalent of \"lower prices\" — the entry point that attracts the first side? → (3) Identify the reinforcement path: does growth in one area automatically feed growth in another? → (4) Find the weak link: which connection in your flywheel is weakest? → (5) Invest in strengthening the weak link — the flywheel is only as strong as its weakest connection → (6) Test: does the system compound — or does it require constant external input to keep spinning?\n- **Key Q**: \"Does my business have a flywheel where each element reinforces the others — or am I manually pushing growth at every step?\"", "sha256": "b453aa04f1766e5275ff59995e41124c3d95cac5cd9913b20a15cef9d6260c3a", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0059", "normalizedDefinition": "Analyze the reinforcing links in Amazon's historical flywheel as a case-derived hypothesis; verify current company facts separately.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "A reinforcing loop still has weak links, congestion and competitive responses. Growth is not automatic and competing against parts of the system is not structurally impossible." }, { "@id": "urn:business-engineer:source-entry:base:60", "@type": "SourceEntry", "id": "base:60", "sourceNumber": 60, "name": "Data Flywheel", "body": "The AI-specific compounding loop: more usage generates more data, more data improves the model, the improved model creates a better product, the better product attracts more usage. Each revolution of the flywheel makes it harder for competitors to catch up because the data advantage compounds — you cannot buy or synthesize the behavioral data generated by millions of real-world interactions. The data flywheel is the primary competitive engine in AI and the foundation of Level 3 moats.\n- **Components**: Usage (users interacting with the product generate data), Data Accumulation (interactions create proprietary training and behavioral data), Model Improvement (more/better data improves model accuracy, speed, and relevance), Product Enhancement (better models create better user experience), Usage Growth (better product attracts more users, generating more data)\n- **Apply**: (1) Map your data flywheel: what data does each user interaction generate? → (2) Assess data quality: is the data generated actually useful for model improvement? → (3) Measure flywheel speed: how quickly does new data translate into product improvement? → (4) Identify bottlenecks: is usage, data quality, model training, or product deployment the constraint? → (5) Accelerate the bottleneck → (6) Measure the gap: how far ahead is your data flywheel compared to competitors? → (7) The wider the gap, the more defensible your position\n- **Key Q**: \"Is my data flywheel spinning — and is the gap between me and competitors widening or narrowing with each revolution?\"", "sha256": "ace9e2c5b04236ddd7890bc309dc8eece8a8cab8588aad020df0ce4c25a63180", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0060", "normalizedDefinition": "Data improves an outcome only if a repeatable learning process converts new observations into better performance and renewed data generation.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Additional data helps only when it is usable, relevant, sufficiently differentiated and improves outcomes economically. Rights, quality, diminishing returns, synthetic substitutes and feedback quality matter. A data collection loop is not automatically a data network effect." }, { "@id": "urn:business-engineer:source-entry:base:61", "@type": "SourceEntry", "id": "base:61", "sourceNumber": 61, "name": "Content Flywheel", "body": "The compounding loop for content-driven businesses: create high-quality content, distribute through channels, build an audience, monetize the audience, reinvest proceeds into better content creation. The key to making this a true flywheel (rather than a linear process) is ensuring that audience growth itself improves content quality and distribution — through feedback, community contributions, algorithmic amplification, and brand credibility. Without this reinforcement, it is just a production line.\n- **Components**: Content Creation (producing valuable, original content), Distribution (reaching audiences through platforms, algorithms, direct channels), Audience Building (growing an engaged, loyal audience), Monetization (converting audience attention into revenue), Reinvestment (channeling revenue back into content quality and distribution)\n- **Apply**: (1) Start with creation: what content can you produce that provides genuine value? → (2) Distribute through the most effective channels for your audience → (3) Build audience with a focus on engagement, not just reach → (4) Monetize in a way that preserves audience trust → (5) Reinvest in creation quality and distribution expansion → (6) The critical question: does your audience itself improve your content? (through feedback, UGC, signal data) → (7) If yes, the flywheel is real; if no, you have a production line that requires constant manual input\n- **Key Q**: \"Does my audience growth itself improve my content quality and distribution — or is this just a linear production process?\"", "sha256": "1e8be53d042b8c0fcd4c4d820af40f25c86fc79a716be121b7e37c96493ef77c", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0061", "normalizedDefinition": "Useful content can attract an audience whose feedback and distribution improve subsequent content; test attention quality, conversion and production cost.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:62", "@type": "SourceEntry", "id": "base:62", "sourceNumber": 62, "name": "Traction-Momentum-Flywheel", "body": "A three-phase growth model: (1) Traction — the earliest phase where the goal is proving value to a small group, demonstrating product-market fit, and generating initial revenue or engagement; (2) Momentum — the scaling phase where proven value is amplified through investment, team growth, and channel expansion; (3) Flywheel — the self-reinforcing phase where growth compounds automatically, requiring less proportional investment for each increment. Most businesses fail because they try to enter the Momentum phase before achieving true Traction, or the Flywheel phase before building real Momentum.\n- **Components**: Traction Phase (proving value, finding PMF, initial revenue/engagement, small-group validation), Momentum Phase (scaling proven model, team growth, channel expansion, market share gains), Flywheel Phase (self-reinforcing growth, compounding advantage, decreasing marginal investment per growth increment)\n- **Apply**: (1) Honestly assess: which phase are you in? Most overestimate → (2) Traction: focus exclusively on proving value for the smallest possible audience — nothing else matters → (3) Momentum: once value is proven, invest in scaling — team, channels, operations → (4) Flywheel: design systems where growth reinforces itself without proportional investment → (5) The transition between phases is the most dangerous moment — premature scaling kills more businesses than competition → (6) Look for phase indicators: Traction = consistent repeat usage; Momentum = growth rate increasing; Flywheel = growth continues even when investment pauses\n- **Key Q**: \"Am I in the Traction, Momentum, or Flywheel phase — and am I doing the right work for that phase?\"", "sha256": "cb1851b6fcf04f5562f1eeff9a04e9fc2e9fd0df2e21c4606b3e7c2e7fc76ea6", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0062", "normalizedDefinition": "Distinguish initial traction, repeatable momentum and a reinforcing growth loop; growth alone does not prove a flywheel.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:63", "@type": "SourceEntry", "id": "base:63", "sourceNumber": 63, "name": "Innovation Flywheel", "body": "The compounding loop for R&D-driven organizations: invest in research and development, generate breakthroughs, convert breakthroughs into market advantages (products, patents, capabilities), generate revenue from those advantages, and reinvest a portion of that revenue back into R&D. The flywheel strengthens when each breakthrough builds on previous ones (cumulative advantage) and when the market advantage generates enough revenue to fund the next breakthrough cycle.\n- **Components**: R&D Investment (allocated resources for research and development), Breakthrough Generation (novel discoveries, inventions, or capabilities), Market Advantage Conversion (turning breakthroughs into products, services, or competitive positions), Revenue Generation (income from the market advantage), Reinvestment (channeling revenue back to R&D), Cumulative Knowledge (each cycle builds on everything learned before)\n- **Apply**: (1) Establish the initial investment: allocate meaningful resources to R&D → (2) Focus on breakthrough potential, not incremental improvement → (3) Build fast conversion capability: reduce time from breakthrough to market advantage → (4) Ensure the market advantage generates sufficient revenue to fund the next cycle → (5) Reinvest with discipline: the ratio of reinvestment determines flywheel speed → (6) Cultivate cumulative knowledge: ensure each breakthrough builds on previous ones, compounding the advantage → (7) The flywheel stalls when reinvestment drops or when breakthroughs stop building on each other\n- **Key Q**: \"Is my innovation flywheel compounding — does each breakthrough build on the last and fund the next?\"", "sha256": "457c7469bc19443d00ffe69cc65115388fc3996d6d512fd06317448c2c50846a", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0063", "normalizedDefinition": "Innovation can reinforce adoption, complementary investment and further innovation when each link has a viable incentive and resource path.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:64", "@type": "SourceEntry", "id": "base:64", "sourceNumber": 64, "name": "AI Priming-Proving Flywheel", "body": "A specific growth loop for AI businesses: AI capabilities prime new use cases (users discover unexpected applications), proven value in those use cases generates demand for more AI capability, increased demand attracts more investment in AI development, more development creates new capabilities that prime further use cases. This flywheel explains why AI adoption accelerates non-linearly — each successful deployment reveals adjacent opportunities that were invisible before the deployment.\n- **Components**: Capability Priming (AI capabilities reveal new, unexpected use cases), Value Proving (successful use cases demonstrate measurable value), Demand Generation (proven value creates demand for additional AI capability), Investment Attraction (demand justifies further AI development investment), Capability Expansion (investment creates new capabilities that prime further use cases)\n- **Apply**: (1) Deploy AI capability and actively watch for unexpected use cases — users will find applications you didn't design for → (2) When unexpected use cases emerge, validate and measure the value created → (3) Use proven value to generate demand: \"This worked here — imagine what it could do there\" → (4) Channel demand into investment in expanded capabilities → (5) New capabilities prime the next cycle of use case discovery → (6) Accelerate the loop by deliberately exposing AI to diverse contexts to maximize priming → (7) The flywheel stalls if you only deploy for planned use cases and ignore emergent ones\n- **Key Q**: \"Am I actively watching for emergent use cases that my AI capabilities are priming — or only measuring the use cases I planned for?\"", "sha256": "138ec187acbe49daf4e81ef55db33efe24e00bcaa0ec581efe2b36b378569d22", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0064", "normalizedDefinition": "Use AI to prepare and test possibilities, then feed verified results into subsequent work; distinguish generated plausibility from observed proof.", "evidence": "Test representative tasks, system boundaries, permission and failure behavior, including an alternative architecture and the cost of review.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:65", "@type": "SourceEntry", "id": "base:65", "sourceNumber": 65, "name": "Asymmetric Business Unit Model", "body": "The structural strategy where a high-margin business unit subsidizes a low-margin business unit, creating a combined competitive position that neither unit could achieve alone. Amazon's AWS (high margin) subsidizing eCommerce (low margin) is the canonical example. The high-margin unit generates the cash flow that allows the low-margin unit to compete at prices no standalone competitor can match, while the low-margin unit builds scale and data advantages that feed back into the high-margin unit's market position.\n- **Components**: Subsidy Unit (high-margin business generating surplus cash flow), Scale Unit (low-margin business using the subsidy to achieve unbeatable competitive position), Cross-Subsidy Mechanism (how cash flows from one unit to the other), Competitive Moat (the combined position is impossible to attack from either side — a competitor cannot match the low margins without the high-margin unit, and cannot build the high-margin unit without the scale unit's market position)\n- **Apply**: (1) Identify your high-margin unit: which part of the business generates surplus cash flow? → (2) Identify or design a low-margin unit that can use that subsidy to build unassailable market position → (3) Establish the cross-subsidy mechanism: how does cash flow from the subsidy unit to the scale unit? → (4) Verify the competitive moat: can a competitor attack either unit independently? → (5) If the moat holds, invest aggressively — the asymmetric structure is itself a compounding advantage → (6) Monitor for risk: if the high-margin unit's profitability declines, the entire structure is threatened\n- **Key Q**: \"Do I have a high-margin unit that can structurally subsidize a low-margin unit to create an unassailable combined position?\"", "sha256": "8d1d2029e48a21bdb93bf8b51002f048e28bcea07e8d706d24ab44227468c32b", "sourceCategory": "VII. FLYWHEELS & GROWTH LOOPS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0065", "normalizedDefinition": "Use a business unit with a different risk, margin or time profile to create options for the wider firm while making subsidies and dependencies visible.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Cross-subsidy requires evidence of cash allocation and causal interaction between units. Do not assume that a profitable cloud segment literally funds a particular retail price reduction without support." }, { "@id": "urn:business-engineer:source-entry:base:66", "@type": "SourceEntry", "id": "base:66", "sourceNumber": 66, "name": "VTDF Framework", "body": "The four-lens analysis for understanding any business model: Value (what value does the business create and for whom?), Technology (what technology enables that value creation?), Distribution (how does the business reach and acquire its users/customers?), and Financial (how does the business generate revenue and manage costs?). The power of VTDF is not in each lens individually — it is in the connections between them. A change in technology can unlock new value propositions, require new distribution, and demand new financial models. Every business model innovation starts with a shift in at least one of these four dimensions.\n- **Components**: Value Model (what problem is solved, for whom, with what unique approach?), Technology Model (what technology enables this, and how does it create advantage?), Distribution Model (how do you reach, acquire, and retain users?), Financial Model (how do you generate revenue, manage costs, and create sustainable margins?)\n- **Apply**: (1) Map any business across all four dimensions → (2) Assess the connections: does the technology enable the value proposition? Does the distribution reach the right audience? Does the financial model sustain the operation? → (3) Identify the weakest dimension: that's the bottleneck → (4) Test for innovation potential: a shift in any one dimension forces re-evaluation of the other three → (5) When analyzing competitors, map their VTDF and look for dimensions they are neglecting → (6) Build your strategy around strength in at least two dimensions and adequacy in the other two\n- **Key Q**: \"Across Value, Technology, Distribution, and Financial — where is my business model strongest, weakest, and most vulnerable to disruption?\"", "sha256": "880c005087f02004bd650c6d3e6f0f03e5b8e343b6f1ffc430510fbfaf8a9baf", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0066", "normalizedDefinition": "Analyze a business through value, technology, distribution and financial dimensions and the tradeoffs connecting them.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:67", "@type": "SourceEntry", "id": "base:67", "sourceNumber": 67, "name": "Catalyst Quadrant (DATC)", "body": "A framework for business renewal that requires operating in four simultaneous modes: (1) Defend — protect existing revenue and market position against current threats; (2) Attack — aggressively pursue competitors' weaknesses and market share; (3) Transform — evolve the business model, capabilities, and culture for the emerging landscape; (4) Create — build entirely new offerings, markets, or business models from scratch. Most organizations default to one or two modes and neglect the others. The BE operates all four simultaneously, allocating resources based on the competitive environment.\n- **Components**: Defend Mode (protect current revenue, strengthen existing moats, repel competitive threats), Attack Mode (exploit competitor weaknesses, capture market share, aggressive positioning), Transform Mode (evolve business model, build new capabilities, prepare for market shifts), Create Mode (build entirely new offerings, enter new markets, innovate from scratch)\n- **Apply**: (1) Assess your current environment: which mode is most urgent? → (2) But do not only operate in the most urgent mode — all four must run simultaneously → (3) Allocate resources: in a crisis, Defend may get 40%; in a growth phase, Attack or Create may dominate → (4) Ensure Transform never goes to zero — organizations that only Defend/Attack without Transforming are optimizing for a world that's disappearing → (5) Ensure Create never goes to zero — organizations that only Transform without Creating become consultants, not builders → (6) Review quadrant allocation quarterly\n- **Key Q**: \"Am I operating in all four modes simultaneously — or am I stuck in only Defend or only Attack?\"", "sha256": "946682380e6c6c98a610165307bf52c7167ff403f4441cd69bce8613b7f5f322", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0067", "normalizedDefinition": "Allocate attention and resources among Defend, Attack, Transform and Create according to the firm's circumstances; review tradeoffs without assuming all four require fixed positive budgets.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Defend, Attack, Transform and Create are useful modes. Operating all four at once is not mandatory when resources or the strategic situation support focused allocation." }, { "@id": "urn:business-engineer:source-entry:base:68", "@type": "SourceEntry", "id": "base:68", "sourceNumber": 68, "name": "Transitional vs Foundational Technology", "body": "A five-layer lifecycle model for understanding technology evolution: (1) Products (0-1 year lifespan — specific applications), (2) Applications (1-5 years — platform-level tools), (3) Transitional Technologies (5-15 years — technologies that bridge current and future paradigms), (4) Foundational Technologies (15-30 years — the underlying platforms that reshape industries), (5) Supercycle Catalysts (30-50 years — the rare mega-forces that reshape entire economies). Understanding which layer a technology operates on determines strategic time horizon, investment horizon, and competitive dynamics.\n- **Components**: Product Layer (0-1yr: specific tools and features — high turnover, low defensibility), Application Layer (1-5yr: platform-level tools — moderate defensibility, evolving rapidly), Transitional Technology Layer (5-15yr: bridges between paradigms — important but temporary), Foundational Technology Layer (15-30yr: the platforms that reshape industries — high defensibility, long-term value), Supercycle Catalyst Layer (30-50yr: economy-reshaping forces — generational transformation)\n- **Apply**: (1) Classify your technology or product: which layer are you operating on? → (2) Product layer: optimize for speed and iteration, expect short lifespan → (3) Application layer: build for broader adoption, invest in UX and ecosystem → (4) Transitional: understand that you are a bridge — build for migration to the foundational layer → (5) Foundational: invest for the long term, build deep moats, expect slow adoption but massive eventual impact → (6) Supercycle: think in decades, position for generational transformation → (7) The strategic error is applying the wrong time horizon to the wrong layer\n- **Key Q**: \"Which technology layer am I operating on — and does my strategy match the time horizon and dynamics of that layer?\"", "sha256": "27dd463d17e58aeaa845681994612e27f95ea940f29e74ba9f522d3b1074cc0c", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0068", "normalizedDefinition": "Distinguish a temporary enabling technology from infrastructure that supports many complementary applications, allowing the classification to change with evidence.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The lifespan bands are illustrative, not empirical clocks. A technology can operate at several layers and persist or be displaced on different schedules." }, { "@id": "urn:business-engineer:source-entry:base:69", "@type": "SourceEntry", "id": "base:69", "sourceNumber": 69, "name": "AI Supercycle Three-Phase Model", "body": "A structural model for the AI transformation of the economy across three sequential phases: (1) Phase 1: AI Eating the Web — AI absorbs and restructures web-native businesses (search, content, commerce, advertising); (2) Phase 2: Industry Restructuring — AI transforms traditional industries (healthcare, manufacturing, finance, education); (3) Phase 3: AI-Native Economic Models — entirely new economic structures, business models, and market mechanisms that only exist because of AI. We are currently in the transition from Phase 1 to Phase 2. Each phase has different winners, strategies, and investment horizons.\n- **Components**: Phase 1 — AI Eating the Web (web-native businesses disrupted first — search, content, commerce, advertising), Phase 2 — Industry Restructuring (traditional industries transformed — healthcare, finance, manufacturing, education), Phase 3 — AI-Native Economic Models (new economic structures that could not exist without AI — agentic economies, autonomous markets)\n- **Apply**: (1) Identify which phase your industry is in → (2) Phase 1 businesses: the disruption is already underway — adapt immediately or be absorbed → (3) Phase 2 industries: prepare now — the restructuring wave is approaching → (4) Phase 3 opportunities: begin exploring AI-native business models that have no pre-AI equivalent → (5) Investment strategy: Phase 1 plays are maturing, Phase 2 plays are emerging, Phase 3 plays are speculative but potentially transformational → (6) The biggest strategic error is assuming your industry won't be affected until Phase 3\n- **Key Q**: \"Which phase of the AI supercycle is my industry in — and am I positioned for the next phase?\"", "sha256": "245038d53e386c0510b0099efb55060f835845ab8152b43ed540992722181a3b", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0069", "normalizedDefinition": "Use AI supercycle phases to organize hypotheses about capability, adoption and economic integration without imposing a universal timetable.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The phases can overlap by sector and geography. Remove the undated claim about where we are currently; establish an as-of date and adoption evidence for any phase assignment." }, { "@id": "urn:business-engineer:source-entry:base:70", "@type": "SourceEntry", "id": "base:70", "sourceNumber": 70, "name": "Business Model Innovation via Margin Conflict", "body": "The strategic use of different margin structures as a competitive weapon — identical to Model 47 (Margin Conflict Strategy) but viewed through the lens of business model innovation rather than competitive attack. The innovation is in the model itself: designing a business that is structurally profitable at margins that would destroy the incumbent's economics. This forces the incumbent into an impossible choice: match the margins (and destroy their own business) or ignore the threat (and cede the market).\n- **Components**: Incumbent Margin Structure (what margins does the market leader require?), Innovative Margin Model (how can you be profitable at fundamentally different margins?), Structural Advantage (what operational, technological, or design advantages enable the different margins?), Forced Cannibalization (the incumbent must destroy value to respond), Time Window (how long before the incumbent adapts or restructures?)\n- **Apply**: (1) Analyze the incumbent's margin requirements: what do they need to satisfy investors, employees, and infrastructure costs? → (2) Design your business model to be profitable at margins that would be catastrophic for the incumbent → (3) Identify the structural advantage that makes your margins sustainable (AI automation, zero marginal cost, different cost structure) → (4) Enter the market: the incumbent now faces forced cannibalization → (5) Move quickly during the time window while the incumbent's internal politics slow their response → (6) Build moats during the window: by the time they adapt, you should be defensible\n- **Key Q**: \"Can I design a business model that is sustainably profitable at margins that would force the incumbent to cannibalize their own business?\"", "sha256": "df05631ae3abfd44ae1028101377ccd828d7cba3895a676c406a34035ce24a46", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0047", "normalizedDefinition": "An incumbent may hesitate to adopt an approach that undermines its existing margin structure; test whether adaptation or segmentation resolves the conflict.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:71", "@type": "SourceEntry", "id": "base:71", "sourceNumber": 71, "name": "Dogfooding Framework", "body": "A four-stage validation framework: (1) Internal Adoption — use your own product internally as the first and most demanding customer; (2) Pain Recognition — systematically identify friction, gaps, and failures through daily usage; (3) Solution Validation — verify that solutions to internal pain points also solve external customer problems; (4) External Validation — launch to the market with confidence that the product has already survived real-world usage. The framework prevents the common failure of building products that pass theoretical tests but fail practical ones.\n- **Components**: Internal Adoption (mandatory use by the building team — not optional, not ceremonial), Pain Recognition (systematic documentation of friction, failures, and gaps discovered through real usage), Solution Validation (internal fixes tested for applicability to external customer problems), External Validation (market launch backed by evidence of real-world usage)\n- **Apply**: (1) Require the entire team to use the product daily for real work — not demos, not tests, real work → (2) Create a structured process for documenting every friction point and failure → (3) Prioritize pain points by frequency and severity → (4) Develop solutions and validate: does fixing this internal pain also solve an external customer problem? → (5) If yes, ship it; if no, it may be an internal-only issue — investigate further → (6) Only declare the product ready for market when internal usage is genuinely productive and pain points are resolved → (7) Continue dogfooding post-launch — it never stops\n- **Key Q**: \"Am I truly using my own product for real work — and are the pain points I'm finding relevant to external customers?\"", "sha256": "9f3d69e70162569da0b21669168c18346e93d20f9087fc8280f31bc404dfa7da", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0071", "normalizedDefinition": "Using one's own product can expose operating problems and accelerate feedback, but employees are not necessarily representative customers.", "evidence": "Define an accepted outcome, baseline and owner; measure total delivery cost, quality, exceptions, attribution and performance after release.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:72", "@type": "SourceEntry", "id": "base:72", "sourceNumber": 72, "name": "AI Implementation Pyramid (4-Tier)", "body": "A resource allocation framework for AI adoption across four tiers of increasing ambition and risk: (1) Tier 1: Productivity Tools (allocate ~70% of AI budget) — use AI to make existing workflows faster and cheaper; (2) Tier 2: Workflow Automation (~15%) — use AI to automate entire workflow segments; (3) Tier 3: Strategic Advantages (~10%) — use AI to create competitive advantages competitors cannot easily replicate; (4) Tier 4: R&D Bets (~5%) — explore speculative AI applications that could transform the business. The pyramid prevents the common error of over-investing in speculative AI while neglecting the guaranteed returns at the base.\n- **Components**: Tier 1 — Productivity Tools (70% allocation: AI for speed, cost reduction, quality in existing workflows), Tier 2 — Workflow Automation (15%: AI replacing entire workflow segments), Tier 3 — Strategic Advantages (10%: AI creating defensible competitive positions), Tier 4 — R&D Bets (5%: speculative AI explorations with transformational potential)\n- **Apply**: (1) Audit current AI spending: does it match the pyramid ratio? → (2) Tier 1 should be the bulk: identify the top 10 workflows where AI can immediately improve productivity → (3) Tier 2: select 2-3 workflow segments ripe for full automation → (4) Tier 3: invest in one strategic AI advantage that competitors cannot easily replicate → (5) Tier 4: allocate a small budget for speculative exploration — accept that most Tier 4 bets will fail → (6) Review and rebalance quarterly → (7) Promote successful Tier 4 bets to Tier 3, Tier 3 successes to Tier 2, as maturity increases\n- **Key Q**: \"Is my AI investment pyramid balanced — or am I over-investing in speculative AI while neglecting guaranteed productivity gains?\"", "sha256": "bf039a1c0960b27915f8919ad2f9ba054eda267d93254ac0bcbc20c6bbd151e1", "sourceCategory": "VIII. BUSINESS MODEL INNOVATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0072", "normalizedDefinition": "Sequence AI adoption according to process readiness, capability requirements, risk and economic value rather than a fixed maturity ladder.", "evidence": "Define an accepted outcome, baseline and owner; measure total delivery cost, quality, exceptions, attribution and performance after release.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The 70/15/10/5 budget split is illustrative. Productivity gains are not guaranteed; allocate after testing process fit, adoption, total cost and measurable outcomes." }, { "@id": "urn:business-engineer:source-entry:base:73", "@type": "SourceEntry", "id": "base:73", "sourceNumber": 73, "name": "Asymmetric Betting Matrix", "body": "A portfolio approach to strategic bets organized by position size and potential return: Micro Bets (0.1-1% of resources, targeting 1000x+ potential return), Small Bets (1-2% of resources, 100-1000x potential), Medium Bets (2-5% of resources, 10-100x potential), and Core Bets (5-10% of resources, 3-10x potential). The matrix recognizes that the most transformational opportunities often require the smallest initial commitments, while the most reliable returns come from larger, more measured bets. The art is in portfolio construction, not individual bet selection.\n- **Components**: Micro Bets (0.1-1% resources, 1000x+ potential — high risk, transformational upside), Small Bets (1-2% resources, 100-1000x potential — speculative but within visibility), Medium Bets (2-5% resources, 10-100x potential — calculated risks with clear thesis), Core Bets (5-10% resources, 3-10x potential — high-conviction, strong evidence)\n- **Apply**: (1) Inventory your strategic bets: what are you currently investing in? → (2) Classify each bet by position size and realistic potential return → (3) Ensure portfolio balance: too many core bets = no upside; too many micro bets = no stability → (4) For micro bets: optimize for quantity and speed — make many small bets, kill losers fast → (5) For core bets: optimize for conviction — deep analysis, high confidence → (6) Rebalance regularly: promote winning micro/small bets to medium/core; cut non-performers → (7) The portfolio is the strategy, not any individual bet\n- **Key Q**: \"Is my strategic portfolio balanced across bet sizes — or am I over-concentrated in either high-risk or low-return positions?\"", "sha256": "5c61f459115c551abab39f58fec08a6c49bf1fd28dfb8b0ca21cba696aed27b0", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0073", "normalizedDefinition": "Compare bets by upside, downside, probability, learning value and affordability; asymmetric payoffs do not guarantee favorable expected value.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The position-size and return ranges are uncalibrated illustrations, not portfolio advice or expected-return estimates. Use actual downside, funding needs, correlation and decision-specific probabilities where defensible." }, { "@id": "urn:business-engineer:source-entry:base:74", "@type": "SourceEntry", "id": "base:74", "sourceNumber": 74, "name": "Impact-Reversibility Matrix", "body": "A decision-making framework that explicitly maps decisions on two axes: Impact (consequences of getting it wrong) and Reversibility (how easily the decision can be undone). The four quadrants: High Impact + Low Reversibility = Strategic Deliberation (slow down, analyze deeply); High Impact + High Reversibility = Smart Experimentation (move fast, you can adjust); Low Impact + Low Reversibility = Careful Consideration (don't rush but don't agonize); Low Impact + High Reversibility = Rapid Iteration (just do it and learn). This prevents the universal enemy of decision-making: treating every decision with the same level of deliberation.\n- **Components**: Strategic Deliberation Quadrant (high impact, low reversibility — critical decisions requiring deep analysis), Smart Experimentation Quadrant (high impact, high reversibility — important but recoverable — move fast), Careful Consideration Quadrant (low impact, low reversibility — minor but sticky — apply appropriate diligence), Rapid Iteration Quadrant (low impact, high reversibility — trivial and fixable — decide immediately)\n- **Apply**: (1) For any pending decision, rate impact (1-10) and reversibility (1-10) → (2) Plot on the matrix → (3) Strategic Deliberation: allocate time, data, and consultation proportional to the stakes → (4) Smart Experimentation: decide quickly, monitor closely, adjust as needed → (5) Careful Consideration: don't agonize but don't rush — apply proportionate diligence → (6) Rapid Iteration: make the call in minutes, not days → (7) The meta-skill: correctly assessing which quadrant a decision belongs in\n- **Key Q**: \"Am I giving this decision the right amount of deliberation for its actual impact and reversibility — or am I over- or under-thinking it?\"", "sha256": "036c0add51c12c16f61f9ed0c1d4d2a893b8a684ebe28f141796bafb85f3f114", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0037", "normalizedDefinition": "Choose an action's speed and commitment according to reversibility, learning value, downside and the cost of delay.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:75", "@type": "SourceEntry", "id": "base:75", "sourceNumber": 75, "name": "Act vs Wait Mental Model", "body": "A framework for the fundamental strategic choice: when to commit resources (Act) versus when to preserve optionality (Wait). Acting is optimal when the cost of delay exceeds the value of additional information, when the opportunity is time-sensitive, or when early commitment creates compounding advantages. Waiting is optimal when uncertainty is high and resolution is near, when the downside of premature commitment exceeds the cost of delay, or when optionality itself has value. Most organizations default to one mode — the BE calibrates dynamically.\n- **Components**: Act Triggers (cost of delay exceeds info value, time-sensitive opportunity, early-mover compounding advantage), Wait Triggers (high uncertainty with imminent resolution, downside of premature commitment, optionality value), Information Value Assessment (will waiting actually reduce uncertainty?), Opportunity Cost Calculation (what do you lose by waiting vs. what do you risk by acting?)\n- **Apply**: (1) For any commitment decision, assess: what is the cost of waiting one more cycle? → (2) Assess: will waiting actually produce meaningful new information? → (3) If waiting costs more than it teaches, act now → (4) If waiting teaches more than it costs, wait → (5) Check for compounding: does acting now create an advantage that grows over time? If yes, the cost of waiting is higher than it appears → (6) Check for optionality: does waiting preserve valuable options that acting would eliminate? If yes, the value of waiting is higher than it appears → (7) The default should be to act unless there is a specific, articulable reason to wait\n- **Key Q**: \"Does the cost of delay exceed the value of waiting for more information — or is optionality more valuable than early commitment right now?\"", "sha256": "51ad949d87865c5164dd60404ed0b889d00d9f6c421ab79a6d9276a805d783a4", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0075", "normalizedDefinition": "Choose between acting and waiting by comparing the value of learning and optionality with the costs of delay and lost opportunities.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:76", "@type": "SourceEntry", "id": "base:76", "sourceNumber": 76, "name": "Bounded Rationality", "body": "The recognition — originating from Herbert Simon and deeply integrated into BE thinking — that humans satisfice rather than optimize. Decision-making is shaped not just by preferences but by the structure of the environment: available information, cognitive limits, time pressure, and the architecture of choice. The BE implication: don't assume rational optimization in your models of human behavior; instead, design for how people actually decide — with limited information, limited time, and heavy reliance on heuristics and environmental cues.\n- **Components**: Satisficing (choosing \"good enough\" rather than optimal), Environmental Structure (the decision architecture shapes the decision), Cognitive Limits (attention, memory, processing constraints), Heuristic Reliance (mental shortcuts that usually work but systematically fail in specific conditions), Design Implication (design products, offers, and systems for bounded rationality, not perfect rationality)\n- **Apply**: (1) When modeling customer, competitor, or stakeholder behavior, do not assume perfect rationality → (2) Ask: what information do they actually have? What are their cognitive constraints? What heuristics are they using? → (3) Design your product/offer for how people actually decide, not how they theoretically should → (4) Simplify choices: reduce cognitive load, make the right option easiest → (5) Structure the environment: the architecture of the choice often matters more than the quality of the options → (6) Recognize your own bounded rationality: use frameworks and checklists to compensate for cognitive limits\n- **Key Q**: \"Am I designing for how people actually decide — or how I assume rational actors should decide?\"", "sha256": "cf0f59acdea539ce8ffa0f6312e6ca6a86daddc37d762df2accdcd58cf449f19", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0076", "normalizedDefinition": "People make decisions under limits of information, time and computation; design processes that fit those limits.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:77", "@type": "SourceEntry", "id": "base:77", "sourceNumber": 77, "name": "Less-is-More Heuristic", "body": "The counterintuitive principle that beyond a certain threshold, more information leads to worse decisions. Additional data creates noise, false patterns, analysis paralysis, and overconfidence. The BE treats information filtering as a strategic capability: knowing what to ignore is as important as knowing what to analyze. This heuristic is especially critical in the AI era, where data abundance is the default and the scarce resource is discernment, not information.\n- **Components**: Information Threshold (the point beyond which additional data degrades decision quality), Noise-to-Signal Ratio (more data often means more noise, not more signal), Analysis Paralysis (excessive information leads to decision avoidance), Overconfidence Trap (more data creates an illusion of precision without improving accuracy), Filtering as Strategy (the deliberate exclusion of information as a competitive advantage)\n- **Apply**: (1) Before gathering more data, ask: will this additional information change my decision? → (2) If the answer is no, stop gathering and decide → (3) Identify the 3-5 data points that actually drive the decision — ignore everything else → (4) Set a time limit: if you haven't decided in X hours with the data available, the constraint is not information — it's decision quality → (5) Practice deliberate information exclusion: for routine decisions, actively limit inputs → (6) Reserve deep analysis for Strategic Deliberation quadrant decisions (high impact, low reversibility) → (7) Treat filtering as a skill to develop, not a shortcut to justify\n- **Key Q**: \"Am I gathering more information because it will improve the decision — or because it feels safer than deciding?\"", "sha256": "e0bff408669a8880554a1264e634c5b1679477f82bdb553a88b606bb76108be6", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0077", "normalizedDefinition": "A simpler rule can outperform a complex one when noise, data scarcity or decision cost outweigh added detail.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:78", "@type": "SourceEntry", "id": "base:78", "sourceNumber": 78, "name": "Ecological Rationality", "body": "The principle that there is no universally best strategy — only strategies better suited to specific environments. A strategy that is optimal in a fast-moving, fragmented market may be catastrophic in a slow-moving, consolidated one. The BE does not seek \"best practices\" — it seeks environment-practice fit. This framework prevents the common error of importing strategies from environments where they succeeded into environments where the conditions for success do not exist.\n- **Components**: Environment Assessment (what type of environment are you operating in — fast/slow, fragmented/consolidated, regulated/unregulated?), Strategy-Environment Fit (does the strategy match the environmental conditions?), Transplant Risk (strategies imported from different environments often fail), Adaptive Repertoire (maintaining multiple strategies for different conditions)\n- **Apply**: (1) Before adopting any strategy, characterize the environment: is it fast or slow? Fragmented or consolidated? Regulated or unregulated? → (2) Assess the strategy's original environment: where did it succeed, and why? → (3) Compare: do the conditions match? → (4) If conditions match, proceed with adaptation → (5) If conditions don't match, do not import — develop an environment-specific strategy → (6) Maintain a repertoire of strategies for different conditions — the ability to switch is itself an advantage → (7) When the environment changes, your strategy must change — loyalty to a strategy in a changed environment is a liability\n- **Key Q**: \"Is this strategy suited to my specific environment — or am I importing something that worked elsewhere under different conditions?\"", "sha256": "49ab77e3a0a754d7eb841a0b80945691711e71f1932dada44b6da32ac6d7085f", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0078", "normalizedDefinition": "A decision rule's quality depends on how well it matches the structure and information of the environment in which it is used.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:79", "@type": "SourceEntry", "id": "base:79", "sourceNumber": 79, "name": "Contradiction Reading", "body": "The analytical practice of treating decisions that violate stated principles as signals of hidden structural drivers operating above individual choice. When a company that claims to prioritize user privacy collects more data, or when a government that advocates free trade imposes tariffs, the contradiction is not hypocrisy — it is evidence. Something at a deeper structural level is compelling the action. The contradiction reveals the structural driver that official narratives cannot acknowledge.\n- **Components**: Stated Principle (what the actor claims to value or prioritize), Observable Action (what the actor actually does), Contradiction Signal (the gap between principle and action), Structural Driver Hypothesis (the deeper force compelling the contradictory action), Validation (does the structural driver explain other contradictions by the same actor?)\n- **Apply**: (1) Observe any action that contradicts the actor's stated principles → (2) Do not dismiss it as hypocrisy — treat it as a signal → (3) Hypothesize: what structural force would make this contradictory action rational or inevitable? → (4) Test the hypothesis: does this structural driver explain other contradictions by the same actor? → (5) If it explains a pattern of contradictions, you've found the real driver → (6) This structural driver is usually more predictive of future actions than any stated principle\n- **Key Q**: \"What structural driver is so powerful that it overrides this actor's stated principles — and what else does it predict?\"", "sha256": "c2eebf4da754bb5ddc463e958a9cc5049415d2ac6157f1772d3dfc7b3d00723d", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0079", "normalizedDefinition": "Treat contradictions between claims or observations as prompts to examine assumptions, units, incentives and regime differences.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "A contradiction is a clue, not proof of a hidden structural imperative. Mistakes, hypocrisy, changed preferences and incomplete public information are competing explanations." }, { "@id": "urn:business-engineer:source-entry:base:80", "@type": "SourceEntry", "id": "base:80", "sourceNumber": 80, "name": "Existential Imperative Test", "body": "The diagnostic question that reveals the deepest driver behind seemingly irrational or surprising actions: \"What catastrophe happens if they don't do this?\" When a company makes a move that seems illogical — overpaying for an acquisition, pivoting away from a profitable business, making a controversial partnership — the answer is almost never stupidity. The answer is almost always an existential threat that is visible to the decision-maker but invisible to outside observers. This test cuts through speculation to the structural logic.\n- **Components**: Surface Action (the seemingly irrational or surprising decision), Existential Question (\"What catastrophe happens if they don't do this?\"), Threat Mapping (what survival-level threat does this action address?), Validation (does this existential threat also explain other puzzling actions?), Predictive Power (what future actions does this existential threat predict?)\n- **Apply**: (1) Observe a decision that seems irrational, surprising, or excessive → (2) Ask: \"What catastrophe happens if they don't do this?\" → (3) Generate hypotheses: what existential threat could make this action rational? → (4) Test: does this threat also explain other seemingly puzzling actions by the same actor? → (5) If yes, you've identified the existential imperative → (6) Use it predictively: what other actions will this existential imperative force? → (7) The existential imperative is the most reliable predictor of organizational behavior — more reliable than strategy documents, earnings calls, or press releases\n- **Key Q**: \"What catastrophe are they trying to prevent — and does that existential threat explain everything else they're doing?\"", "sha256": "22f8dffbb0a3a1128db62661b6190d93ae7e235fb4d57be920f0f464187c7312", "sourceCategory": "IX. DECISION-MAKING & OPTIMIZATION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0080", "normalizedDefinition": "Determine which strategic requirement is necessary for continued viability and distinguish it from attractive but optional improvements.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "An existential threat is one hypothesis. Compare ordinary uncertainty, poor execution, incentives and strategic error; do not turn every surprising choice into a rational survival response." }, { "@id": "urn:business-engineer:source-entry:base:81", "@type": "SourceEntry", "id": "base:81", "sourceNumber": 81, "name": "AI-Native Organizational Archetypes", "body": "Four emerging organizational structures designed for the AI era, each reflecting a different philosophy of human-AI collaboration: (1) Two-Layer Revolution — a thin strategic layer of humans directing an AI execution layer; (2) Trust Network — small autonomous teams connected by shared protocols and AI coordination; (3) Slime Mold Organization — a fluid, self-organizing structure that reshapes continuously in response to the environment, with AI as the connective tissue; (4) Micro-Empire — a single individual or tiny team leveraging AI to achieve the output of a much larger organization. The principle: structure determines strategy — the organizational form you choose constrains the strategies available to you.\n- **Components**: Two-Layer Revolution (thin human strategy layer + AI execution layer — fast, scalable, but requires excellent strategic thinking at the top), Trust Network (autonomous teams + shared protocols + AI coordination — resilient, innovative, but requires deep trust and clear protocols), Slime Mold Organization (fluid self-organization + AI connective tissue — adaptive, responsive, but hard to manage and measure), Micro-Empire (individual/tiny team + AI augmentation achieving enterprise-level output — agile, low-cost, but limited by key-person risk)\n- **Apply**: (1) Assess your current organizational structure: which archetype are you closest to? → (2) Assess the environment: which archetype best fits your competitive landscape? → (3) If building new: choose the archetype that matches your strategy and culture → (4) If transforming: identify the target archetype and design the transition → (5) Each archetype has strengths and vulnerabilities — no archetype is universally best → (6) The key question is fit: does the structure enable the strategy, or does the structure constrain it?\n- **Key Q**: \"Which organizational archetype best fits my strategy, culture, and competitive environment — and is my current structure enabling or constraining me?\"", "sha256": "0d181c6c21b58cb12bcec5e1ad37f3ca28aaecaac6fc3246d0ff68ab403e4814", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0081", "normalizedDefinition": "Compare organizational forms for AI work by where expertise, authority, execution and learning reside; no single archetype fits every firm.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:82", "@type": "SourceEntry", "id": "base:82", "sourceNumber": 82, "name": "Super Individual Contributor", "body": "The emerging role of individual contributors who combine deep technical or domain expertise with strategic thinking, creating disproportionate value through AI augmentation. The Super IC is not a manager who lost their team — it is a fundamentally new role where one person, augmented by AI, can produce the output of a small team or department across creation, analysis, strategy, and execution. This role challenges traditional organizational hierarchies and raises fundamental questions about team structure and value distribution.\n- **Components**: Deep Expertise (domain or technical mastery that provides judgment AI cannot replace), Strategic Thinking (ability to connect expertise to business outcomes), AI Augmentation (systematic use of AI to multiply output capacity), Cross-Functional Output (ability to produce across creation, analysis, strategy, and execution), Disproportionate Value (output significantly exceeding what the role traditionally produced)\n- **Apply**: (1) Identify individuals in your organization who combine deep expertise with strategic thinking → (2) Equip them with AI tools that amplify their specific strengths → (3) Remove organizational barriers that force them to specialize or manage → (4) Measure by output and value, not by activity or team size → (5) Restructure compensation to reflect disproportionate value creation → (6) Recognize: Super ICs may outperform entire teams — design the organization to accommodate this → (7) The Super IC is not a replacement for teams — it is a new organizational primitive that changes how teams are constructed\n- **Key Q**: \"Am I creating conditions for Super ICs to emerge — or is my organizational structure forcing everyone into traditional roles?\"", "sha256": "703b25b7b0d1606a61a86d1168e377aacfdb8762da3234e1d984b5af771bd0a1", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0082", "normalizedDefinition": "AI can expand an individual's effective scope when task verification, context and coordination remain manageable.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The role describes possible scope expansion. Team-equivalent output is task-dependent and must include quality, review and coordination costs." }, { "@id": "urn:business-engineer:source-entry:base:83", "@type": "SourceEntry", "id": "base:83", "sourceNumber": 83, "name": "Permanent Beta Organization", "body": "An organizational philosophy built for continuous adaptation rather than periodic reorganization. Traditional organizations alternate between stability and painful, disruptive reorganizations. The Permanent Beta organization treats change as the default state — every process, structure, and strategy is provisional, constantly tested, and evolved. This is not chaos — it is disciplined adaptability, where the organization maintains just enough structure to execute while preserving enough flexibility to evolve.\n- **Components**: Provisional Everything (all processes, structures, and strategies are treated as hypotheses to be tested), Continuous Adaptation (change is constant and incremental, not periodic and disruptive), Minimum Viable Structure (just enough organization to execute, not so much that it resists change), Adaptation Rituals (regular reviews of what's working and what needs to evolve), Psychological Safety (people must feel safe challenging and changing established practices)\n- **Apply**: (1) Audit your organization: which structures are treated as permanent and which as provisional? → (2) For each \"permanent\" structure, ask: is this still serving us, or is it just familiar? → (3) Institute adaptation rituals: monthly reviews of processes, quarterly reviews of structures, annual reviews of strategy → (4) Reward adaptation: celebrate people who identify and improve outdated processes → (5) Maintain minimum viable structure: enough to execute, not so much that it resists necessary change → (6) Accept discomfort: permanent beta means never fully \"done\" — that's the feature, not the bug\n- **Key Q**: \"Is my organization built for continuous adaptation — or does it alternate between rigid stability and painful, disruptive reorganization?\"", "sha256": "394325ae4dd658e83774af9a0f517535488f7fe76c05d8f2b69981dbc2c5c76b", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0083", "normalizedDefinition": "Maintain a capacity for controlled experimentation and revision while preserving stable commitments, accountability and reliable operations.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:84", "@type": "SourceEntry", "id": "base:84", "sourceNumber": 84, "name": "FRED Test", "body": "An AI Transformation Reality Check framework for assessing enterprise AI readiness. The acronym and dimensions force honest assessment of whether an organization is genuinely ready for AI transformation or merely engaged in AI theater. The FRED Test prevents the common failure of investing millions in AI initiatives that produce impressive demos but no structural business value, by checking foundational readiness before commitment.\n- **Components**: Foundational Readiness (data infrastructure, technical capabilities, integration readiness), Resource Allocation (budget, talent, time committed to AI transformation), Executive Alignment (leadership commitment beyond lip service — are they willing to restructure?), Deployment Capability (ability to move from proof-of-concept to production at scale)\n- **Apply**: (1) Rate the organization on each FRED dimension (1-10) → (2) Foundational: is the data infrastructure actually capable of supporting AI? (Most fail here) → (3) Resources: are real resources allocated, or is AI getting scraps from the innovation budget? → (4) Executive: are leaders willing to make structural changes, or do they want AI results without organizational change? → (5) Deployment: can the organization move from POC to production, or do proofs-of-concept die in the lab? → (6) If any dimension scores below 4, address that dimension before investing further in AI initiatives → (7) Be honest: AI theater is expensive and demoralizing\n- **Key Q**: \"Is my organization genuinely ready for AI transformation — or are we investing in AI theater?\"", "sha256": "56cf96bf4ed32e83bd0cfc2f3540b96d2be91fb9be597fa2e4b7ca54e613a0b9", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0084", "normalizedDefinition": "Assess Foundational Readiness, Resource Allocation, Executive Alignment and Deployment Capability using observable evidence; ratings and gating thresholds require local calibration.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "FRED means Foundational Readiness, Resource Allocation, Executive Alignment and Deployment Capability in this supplied formulation. Scores below 4 on a 1–10 scale are not a validated threshold; use observed evidence and explicit gates." }, { "@id": "urn:business-engineer:source-entry:base:85", "@type": "SourceEntry", "id": "base:85", "sourceNumber": 85, "name": "AI Discernment Framework", "body": "A framework for evaluating AI capabilities versus limitations in specific business contexts — preventing both over-reliance on AI (using it where it will fail) and under-utilization (not using it where it would excel). The framework recognizes that AI's capability profile is uneven: it is extraordinary at some tasks and unreliable at others, and the boundary shifts rapidly. The BE uses this framework to make investment and deployment decisions about AI applications.\n- **Components**: Capability Assessment (what can AI reliably do in this specific context?), Limitation Mapping (where does AI fail, hallucinate, or produce unreliable results?), Context Specificity (capabilities vary by domain, data quality, and task type), Boundary Monitoring (the capability-limitation boundary shifts rapidly — track it), Risk Calibration (what is the cost of AI failure in this application?)\n- **Apply**: (1) For any proposed AI application, assess: what can AI reliably do here today? → (2) Map limitations: where will it fail, and what are the consequences of failure? → (3) Evaluate context: do we have the right data, domain knowledge, and infrastructure for reliable AI performance? → (4) Calibrate risk: if AI fails in this application, what is the cost? → (5) Deploy AI where capabilities are strong and failure costs are manageable → (6) Maintain human oversight where limitations are known and failure costs are high → (7) Reassess regularly — the boundary moves fast\n- **Key Q**: \"Where does AI genuinely excel in my context, where does it fail, and what is the cost of getting it wrong?\"", "sha256": "c832453a196c4d415c70efc9259168223a494b0b332a94d9f0b2dfda5f9fbc8b", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0085", "normalizedDefinition": "Judge when an AI output is useful, sufficiently reliable and appropriate to act on, including when expertise or verification is missing.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:86", "@type": "SourceEntry", "id": "base:86", "sourceNumber": 86, "name": "Dual-Engine Framework", "body": "The organizational model for running core business optimization and AI transformation as parallel, simultaneous operations rather than sequential phases. Engine 1 (Core Business) focuses on optimizing current operations, revenue, and efficiency. Engine 2 (AI Transformation) focuses on building new capabilities, models, and competitive positions. Both engines must run simultaneously with dedicated resources, separate metrics, and clear interfaces between them. Organizations that try to do AI transformation within the core business structure almost always fail.\n- **Components**: Engine 1 — Core Business (current operations optimization, revenue growth, efficiency improvement — measured by traditional business metrics), Engine 2 — AI Transformation (new capability building, model development, competitive positioning — measured by learning speed, capability milestones, strategic positioning), Resource Separation (each engine gets dedicated resources, not shared scraps), Interface Design (clear protocols for how the two engines communicate and transfer value)\n- **Apply**: (1) Separate the two engines organizationally — AI transformation cannot be a \"side project\" within the core business → (2) Allocate dedicated resources to each engine — not leftovers from the other → (3) Define separate metrics: Core Business = revenue, margin, efficiency; AI Transformation = learning speed, capability milestones, strategic positioning → (4) Design the interface: how do insights and capabilities transfer between engines? → (5) Protect Engine 2 from Engine 1's short-term pressures — this is the CEO's primary responsibility → (6) Plan the convergence: eventually the engines merge, but premature convergence kills transformation\n- **Key Q**: \"Am I running core optimization and AI transformation as parallel engines with separate resources — or am I expecting the core business to transform itself?\"", "sha256": "932d31cab1d9a184249939f4c9ceb64d67ce2698ca13dc9436462cb13bf178c3", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0086", "normalizedDefinition": "Operate existing revenue and emerging capabilities with explicit resource allocation and interfaces so one does not silently starve the other.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Separate engines can protect transformation work, but separation is not universally superior. Test the cost of duplicated systems, handoffs, incentives and isolation from real operations." }, { "@id": "urn:business-engineer:source-entry:base:87", "@type": "SourceEntry", "id": "base:87", "sourceNumber": 87, "name": "Productivity Spectrum", "body": "The framework for understanding how AI expands individual capability beyond traditional productivity metrics, enabling individuals to perform at team-level competencies. Traditional productivity measures output per unit of time. The Productivity Spectrum recognizes that AI augmentation doesn't just make individuals faster — it expands the range of what they can do. A single person with AI augmentation can now handle strategy, execution, analysis, design, and communication that previously required a specialized team.\n- **Components**: Traditional Productivity (output per unit of time — the old metric), Capability Expansion (range of competencies an individual can now perform), Team-Level Competency (individual performing tasks that previously required multiple specialists), Output Quality vs. Quantity (AI doesn't just increase volume — it can improve quality across a wider range), New Value Creation (capability combinations that were impossible before AI augmentation)\n- **Apply**: (1) Audit current workflows: where are individuals limited by specialization, not capability? → (2) Identify AI tools that expand individual capability range → (3) Measure by capability expansion, not just speed improvement → (4) Redesign roles around expanded capability: can one person + AI do what a team of three did? → (5) Restructure teams: fewer, more capable individuals rather than many narrow specialists → (6) Invest in generalist-specialist hybrids: people who combine deep expertise in one area with AI-augmented competency across many → (7) Rethink compensation: value should reflect capability range, not just specialization depth\n- **Key Q**: \"Am I measuring AI productivity only as speed improvement — or am I capturing the full capability expansion it enables?\"", "sha256": "9bb6e155af773e69413dcae3a9ce9e138f2223e8ca54fe0895b815496c890fd7", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0087", "normalizedDefinition": "Evaluate productivity at task, workflow and organizational levels, including quality, rework and displaced bottlenecks.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:88", "@type": "SourceEntry", "id": "base:88", "sourceNumber": 88, "name": "Stupid-Out Matrix", "body": "A framework for building teams in the AI age by filtering candidates and roles through two dimensions: Capability (can they do the work?) and Adaptability (can they evolve as the work changes?). The matrix creates four quadrants: High Capability + High Adaptability (Stars — invest and retain), High Capability + Low Adaptability (Specialists — valuable now but risky long-term), Low Capability + High Adaptability (Potential — develop rapidly), Low Capability + Low Adaptability (Exit — redirect immediately). In the AI age, adaptability is weighted more heavily than in previous eras because the work itself is changing continuously.\n- **Components**: Stars (high capability + high adaptability — the core of AI-age teams), Specialists (high capability + low adaptability — valuable but vulnerable to change), Potential (low current capability + high adaptability — fast learners who will become stars with investment), Exit Zone (low capability + low adaptability — honest reassignment is kinder than pretending)\n- **Apply**: (1) Map your current team across both dimensions → (2) Stars: invest heavily, give maximum autonomy and AI tools → (3) Specialists: leverage their current value but invest in developing adaptability → (4) Potential: pair with mentors and AI tools, accelerate development → (5) Exit Zone: have honest conversations about fit and transition → (6) In hiring, weight adaptability more heavily than current capability — in a rapidly changing environment, the ability to learn matters more than what you already know → (7) Reassess regularly — people move between quadrants\n- **Key Q**: \"Am I building my team for the work that exists today — or the work that will exist tomorrow?\"", "sha256": "d4b3ae44e0d80a763aa7667e95041aa60b0dd6cc5c62c81bba83d535dd3aa6cd", "sourceCategory": "X. ORGANIZATIONAL DESIGN & AI ADOPTION", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0088", "normalizedDefinition": "Compare capability with willingness and ability to adapt; use a neutral diagnostic rather than treating people as fixed derogatory categories.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Use Capability and Adaptability Matrix as the neutral working label; retain Stupid-Out Matrix as a legacy search alias. Assess role-relevant evidence and development needs. A quadrant is not sufficient evidence for an employment decision." }, { "@id": "urn:business-engineer:source-entry:base:89", "@type": "SourceEntry", "id": "base:89", "sourceNumber": 89, "name": "Incumbent Vulnerability Analysis", "body": "A systematic framework for identifying where established players are most exposed to disruption, analyzing multiple vulnerability dimensions: market position (are they complacent?), technology debt (are they stuck on legacy systems?), organizational rigidity (can they adapt?), margin dependency (are they trapped by high-margin expectations?), and customer dissatisfaction (are users loyal or captive?). The framework provides a structured approach to finding the cracks in seemingly invincible market leaders.\n- **Components**: Market Position Complacency (has the incumbent stopped innovating because they feel safe?), Technology Debt (are legacy systems creating structural disadvantages?), Organizational Rigidity (can the incumbent adapt its structure, culture, and processes?), Margin Dependency (is the incumbent trapped by investor expectations for high margins?), Customer Dissatisfaction (are users genuinely loyal or simply lacking alternatives?)\n- **Apply**: (1) Select an incumbent to analyze → (2) Score each vulnerability dimension (1-10) based on observable evidence → (3) Market Position: look for signs of complacency — declining innovation, ignored complaints, internal focus → (4) Technology Debt: assess how much legacy infrastructure constrains their ability to adopt new approaches → (5) Organizational Rigidity: evaluate leadership's willingness and ability to change → (6) Margin Dependency: analyze how their margin structure constrains competitive response → (7) Customer Dissatisfaction: talk to customers — loyalty and lock-in look the same from outside but feel very different from inside → (8) The highest-scoring dimensions are the attack surfaces\n- **Key Q**: \"Where is this incumbent most structurally vulnerable — and is it in a dimension I can exploit?\"", "sha256": "41342c821592fefcbf3cbf61b3933882a5526383abb98cbe7a19464b4e88b077", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0089", "normalizedDefinition": "Assess incumbent vulnerability through incentives, architecture, distribution, resources and adaptation paths rather than size or age alone.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:90", "@type": "SourceEntry", "id": "base:90", "sourceNumber": 90, "name": "Market Structure Dynamics", "body": "An analytical framework for understanding how market structures evolve over time and what drives transitions between states: Fragmented (many small players, no dominant force), Consolidating (winners emerging, share concentrating), Oligopoly (few large players dominating), and Monopoly/Dominant Player (one player controls the market). Each state has different competitive strategies, and understanding the transition dynamics — what forces push a market from one state to another — is more valuable than understanding the current state alone.\n- **Components**: Fragmented State (many small players, low barriers, high competition, innovation-driven), Consolidating State (winners emerging, M&A increasing, scale advantages appearing), Oligopoly State (few large players, high barriers, competition on efficiency and brand), Monopoly/Dominant State (one player controls, regulation becomes the primary competitive factor), Transition Drivers (technology shifts, regulation changes, network effects, capital concentration)\n- **Apply**: (1) Classify your market's current structural state → (2) Identify the transition drivers: what forces are pushing the market toward the next state? → (3) Fragmented → Consolidating: look for scale advantages and acquisition opportunities → (4) Consolidating → Oligopoly: invest in moats and differentiation before the market locks → (5) Oligopoly → Monopoly: either become the dominant player or find the niche the dominant player cannot serve → (6) At any state: look for disruption forces that could reset the market back to fragmented → (7) Strategy must match not just the current state but the direction of transition\n- **Key Q**: \"What market structure state am I in, where is it heading, and is my strategy aligned with the transition dynamics?\"", "sha256": "0c30bfb1c26f6f36022d553549bde9e5c2062d506802199ef790dec57469cdbc", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0090", "normalizedDefinition": "Explain market outcomes through entry barriers, differentiation, scale effects, bargaining positions and evolving concentration.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:91", "@type": "SourceEntry", "id": "base:91", "sourceNumber": 91, "name": "Capital Asymmetry of AI", "body": "A framework for analyzing how AI investment concentrates in a small number of players and what this concentration means for competitive dynamics. The capital asymmetry creates a structural divide: a handful of \"hyperscalers\" (with billions in compute, data, and talent investment) and everyone else. This framework examines how smaller players can compete despite the asymmetry — through specialization, efficiency, niche focus, or by riding the hyperscalers' infrastructure.\n- **Components**: Capital Concentration (where is AI investment concentrating — which companies, which layers?), Structural Divide (the widening gap between hyperscalers and everyone else), Competition Despite Asymmetry (strategies for competing without matching capital: specialization, efficiency, niche focus), Dependency Analysis (how dependent is your strategy on hyperscaler infrastructure?), Asymmetry Trajectory (is the gap widening or narrowing — and what would change the trajectory?)\n- **Apply**: (1) Map the capital landscape: who is spending how much on AI, and where? → (2) Assess your position: are you a hyperscaler, a mid-tier player, or a small player? → (3) If small/mid-tier: do not try to compete head-on with hyperscalers on compute or general models → (4) Instead, compete on specialization (deep domain expertise), efficiency (better results with less compute), niche focus (serving segments hyperscalers ignore), or leverage (building on hyperscaler infrastructure) → (5) Monitor dependency: if your strategy depends on a hyperscaler, understand the implications → (6) Watch for asymmetry shifts: technology breakthroughs (efficient models, edge AI) can reduce capital requirements\n- **Key Q**: \"How can I compete in AI despite not having hyperscaler-level capital — and what strategy fits my actual resource position?\"", "sha256": "6bf006a004f42c2e69ad8ef55c87e45d70e78821555bfc96e3925ffe99eb86a4", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0091", "normalizedDefinition": "AI participants face different funding needs and access to capital; trace how those differences affect timing, resilience and strategic choices.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:92", "@type": "SourceEntry", "id": "base:92", "sourceNumber": 92, "name": "AI Bubble vs Supercycle", "body": "A diagnostic framework for distinguishing between short-term hype cycles (bubbles) and long-term fundamental transformations (supercycles) in AI. Bubbles are characterized by speculative capital, unrealistic valuations, and limited real-world adoption. Supercycles are characterized by fundamental infrastructure investment, broad industry adoption, and measurable productivity gains. The same asset can be simultaneously in a bubble (overpriced in the short term) and a supercycle (transformational in the long term). The framework helps investors and strategists separate timing from thesis.\n- **Components**: Bubble Indicators (speculative capital, unrealistic valuations, limited adoption, hype-driven narratives), Supercycle Indicators (infrastructure investment, industry adoption, productivity gains, foundational technology change), Timing vs. Thesis Separation (the thesis can be right while the timing is wrong), Phase Assessment (where are we in the cycle — early hype, bubble peak, correction, real adoption?), Strategic Implication (how to position for both the short-term correction and the long-term transformation)\n- **Apply**: (1) Assess current AI investment: is it driven by speculation (bubble) or fundamental infrastructure (supercycle)? → (2) Look for bubble indicators: are valuations based on revenue or hope? Is adoption real or theoretical? → (3) Look for supercycle indicators: are large companies restructuring around AI? Are productivity gains measurable? → (4) The most likely answer: both — AI is simultaneously a bubble (some segments are overpriced) and a supercycle (the fundamental transformation is real) → (5) Position for both: don't dismiss AI as a bubble, but don't overpay for hype → (6) Focus on the supercycle fundamentals: infrastructure, adoption, productivity\n- **Key Q**: \"Is this specific AI investment a bubble play or a supercycle play — and am I positioned to survive the correction while capturing the transformation?\"", "sha256": "6114aa96a0fa3a60171233206b0ab80a2746fcfa1edbace8ab7ed7162994b58b", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0092", "normalizedDefinition": "Separate inflated asset prices or financing expectations from durable technology adoption; speculative losses and useful infrastructure can coexist.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Assess technology adoption, asset valuation and financing resilience separately. Transformation can coexist with poor investor returns, and strong adoption alone does not establish an attractive price." }, { "@id": "urn:business-engineer:source-entry:base:93", "@type": "SourceEntry", "id": "base:93", "sourceNumber": 93, "name": "Technology Supercycle", "body": "A historical framework for understanding 30-50 year transformation waves and how the current AI supercycle compares to previous ones (electricity, automobile, internet, mobile). Each supercycle follows a pattern: initial invention → speculative investment → crash/correction → real infrastructure buildout → mass adoption → industry restructuring → new economic paradigm. Understanding where AI is in this pattern — and where previous supercycles were at the same stage — provides strategic orientation that short-term analysis cannot.\n- **Components**: Invention Phase (the core technology breakthrough), Speculative Phase (excessive investment driven by potential, not reality), Correction Phase (bubble bursts, weak players eliminated, capital redirects), Infrastructure Phase (real buildout of the enabling infrastructure), Mass Adoption Phase (the technology becomes ubiquitous), Industry Restructuring Phase (existing industries fundamentally transformed), New Economic Paradigm (entirely new economic models emerge)\n- **Apply**: (1) Study previous supercycles: electricity (1880s-1930s), automobile (1900s-1950s), internet (1990s-2020s), mobile (2007-2030s) → (2) Map the AI supercycle against the pattern: where are we? (likely late speculative / early correction / early infrastructure) → (3) What happened at this stage in previous supercycles? Who won and who lost? → (4) Position for the infrastructure phase: that's where lasting competitive positions are built → (5) Do not confuse the correction (bubble bursting) with the end of the supercycle — the transformation is just beginning → (6) Plan on a 30-50 year horizon: what will the AI-transformed economy look like?\n- **Key Q**: \"Where is AI in the supercycle pattern — and what does history tell us about what happens next?\"", "sha256": "169edf9cd6004a3d25ac77672c38ec17a90b5446522f95e3e9d511f4b7a46771", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0093", "normalizedDefinition": "A technology buildout can involve investment ahead of demand, local failures and later reuse; historical analogies require matched mechanisms and dates.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Historical waves differ in duration and sequence. A crash is not required before useful deployment, and 30–50 years is not a forecasting law. Verify the historical mechanism before transferring it." }, { "@id": "urn:business-engineer:source-entry:base:94", "@type": "SourceEntry", "id": "base:94", "sourceNumber": 94, "name": "Negotiation Leverage Matrix", "body": "A framework for systematically identifying, building, and deploying leverage in business negotiations. Leverage comes from multiple sources: BATNA (best alternative to negotiated agreement — your ability to walk away), Information Asymmetry (knowing things the other side doesn't), Time Pressure (who needs the deal closed faster), Relationship Capital (trust and goodwill accumulated over time), and Structural Position (market dynamics that favor one side). The framework maps all leverage sources for both sides, revealing the true power balance before negotiation begins.\n- **Components**: BATNA Strength (how good is your alternative if this deal fails?), Information Asymmetry (what do you know that the other side doesn't — and vice versa?), Time Pressure (who is under more urgency to close?), Relationship Capital (accumulated trust, goodwill, and reputation), Structural Position (market dynamics, supply/demand balance, competitive alternatives)\n- **Apply**: (1) Before any negotiation, map all five leverage sources for both sides → (2) BATNA: strengthen yours before entering — the ability to walk away is the most powerful lever → (3) Information: identify what you know that they don't and what they likely know that you don't → (4) Time: assess who is under more pressure — and never reveal your own time pressure → (5) Relationship: leverage accumulated trust, but never spend it recklessly → (6) Structural: understand market dynamics that favor or disadvantage your position → (7) The side with more leverage sources wins — but only if they deploy them deliberately\n- **Key Q**: \"Where does the real leverage sit in this negotiation — and have I strengthened my position across all five sources before entering?\"", "sha256": "60a543b7c15d6e97ba8241b22ac026d5ff83aaa813e43e2d60b628b2926dd04a", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0094", "normalizedDefinition": "Negotiating power depends on credible alternatives, dependency, information, timing and the ability to commit or walk away.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:95", "@type": "SourceEntry", "id": "base:95", "sourceNumber": 95, "name": "Comparable Company Analysis", "body": "A systematic method for evaluating businesses against relevant peer sets — not just financial comparisons but structural, strategic, and positional comparisons. Traditional comp analysis compares revenue multiples and growth rates. The BE version adds structural dimensions: moat quality, flywheel strength, market position trajectory, and strategic archetype alignment. This produces a richer evaluation that reveals whether a company is genuinely comparable to its supposed peers or structurally different in ways that financial metrics alone cannot capture.\n- **Components**: Financial Comparison (revenue, margins, growth rates, valuation multiples), Structural Comparison (moat type and strength, flywheel maturity, constraint profile), Strategic Comparison (archetype alignment, competitive positioning, market layer), Positional Comparison (market share trajectory, customer loyalty indicators, brand strength), Divergence Detection (where does this company look comparable on financials but diverge structurally?)\n- **Apply**: (1) Define the peer set: which companies are genuinely comparable in market, strategy, and structure? → (2) Compare financials: revenue, margins, growth, valuation — the baseline → (3) Compare structurally: moat quality, flywheel maturity, binding constraints → (4) Compare strategically: are they the same archetype, targeting the same layer, with the same competitive logic? → (5) Compare positionally: is their market position strengthening or weakening relative to peers? → (6) Identify divergences: where do financials look similar but structural or strategic positions diverge? → (7) The divergences are the insight — they reveal mispricing, hidden risk, or hidden opportunity\n- **Key Q**: \"Is this company truly comparable to its supposed peers — or do structural and strategic differences make the financial comparison misleading?\"", "sha256": "55d4229428b832e1d56c992fa98c62e9e4fd9cbc0619bacc025470680b3ca2e3", "sourceCategory": "XI. MARKET & INDUSTRY ANALYSIS", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0095", "normalizedDefinition": "Use comparable companies only after aligning business exposure, accounting, growth, risk and capital needs; a multiple is a comparison, not an explanation.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:96", "@type": "SourceEntry", "id": "base:96", "sourceNumber": 96, "name": "Agentic Web Visibility Playbook", "body": "A strategic framework for maintaining and growing visibility when AI agents — not human users — increasingly mediate discovery and commerce. In the emerging agentic web, AI agents make purchasing recommendations, filter information, and route traffic based on criteria that differ fundamentally from human browsing behavior. Visibility strategies designed for human eyeballs (SEO, social media, advertising) must be supplemented or replaced by strategies designed for agent cognition: structured data, protocol compliance, authority signals, and machine-readable value propositions.\n- **Components**: Agent Discovery Optimization (how AI agents find and evaluate your offering), Structured Data Architecture (machine-readable information that agents can process), Protocol Compliance (adherence to emerging agent communication standards), Authority Signals (indicators that agents use to assess trustworthiness and quality), Machine-Readable Value Proposition (your offering expressed in formats agents can parse and compare)\n- **Apply**: (1) Audit your current visibility strategy: is it designed for human browsers or AI agents? → (2) Implement structured data that agents can parse: schema markup, APIs, standardized formats → (3) Ensure protocol compliance: adopt emerging agent communication standards early → (4) Build authority signals: consistent quality, verified credentials, institutional endorsements → (5) Express your value proposition in machine-readable formats, not just human-readable copy → (6) Monitor agent-mediated traffic: how are AI agents finding and presenting your offering? → (7) This is not replacing human-focused visibility — it is adding an agent-focused layer\n- **Key Q**: \"Is my visibility strategy designed for AI agents as well as human users — or am I invisible to the emerging agentic discovery layer?\"", "sha256": "8441bf18ee9d240d3f0041acdd604e9ca73cd2d5f074a2170484f7c3c41ec719", "sourceCategory": "XII. DISTRIBUTION & VISIBILITY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0096", "normalizedDefinition": "Assess whether agents can discover, interpret and cite an entity in relevant tasks; visibility is distinct from transaction authority or conversion.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Treat machine-readable content as one possible contributor to discoverability. Current platform behavior, coverage and commercial impact require measurement." }, { "@id": "urn:business-engineer:source-entry:base:97", "@type": "SourceEntry", "id": "base:97", "sourceNumber": 97, "name": "Digital Distribution Layers", "body": "A framework mapping how content and products flow through three distinct distribution layers: Platform Distribution (reach determined by platform algorithms and rules — YouTube, App Store, Google), Algorithmic Distribution (reach amplified or suppressed by recommendation algorithms — feeds, suggestions, rankings), and Direct Distribution (reach controlled by the creator/company — email, owned communities, direct relationships). Each layer has different control levels, scalability, and vulnerability. Over-dependence on any single layer is a strategic risk.\n- **Components**: Platform Layer (distribution controlled by platform gatekeepers — rules, fees, visibility), Algorithmic Layer (distribution shaped by recommendation engines — amplification, suppression, ranking), Direct Layer (distribution controlled by the creator/company — email lists, communities, direct relationships), Layer Diversification (spreading distribution across all three to reduce dependency), Control Assessment (how much control do you have at each layer?)\n- **Apply**: (1) Map your current distribution: what percentage flows through platform, algorithmic, and direct channels? → (2) Assess vulnerability: if one layer changes its rules, how much traffic do you lose? → (3) Platform layer: maintain presence but do not depend — platform rules change without notice → (4) Algorithmic layer: understand the algorithm's incentives and optimize accordingly, but do not build your entire strategy on it → (5) Direct layer: invest heavily — this is the only layer you truly control → (6) Target: at least 30% of distribution through direct channels → (7) Diversify across all three, with increasing investment in direct over time\n- **Key Q**: \"How much of my distribution do I actually control — and what happens if the platforms or algorithms change their rules?\"", "sha256": "b01249d78711a39829fd29d5f48d92bbe7233a8eac61dcfa8237b5517b3334ee", "sourceCategory": "XII. DISTRIBUTION & VISIBILITY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0097", "normalizedDefinition": "Separate distribution layers and their interfaces to identify who controls access, demand, discovery and monetization.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:98", "@type": "SourceEntry", "id": "base:98", "sourceNumber": 98, "name": "Brand Authority in AI Agent Age", "body": "A framework for understanding why brand becomes even more critical when AI agents make purchasing and recommendation decisions. Counterintuitively, as AI agents mediate more decisions, human brand perception matters more, not less — because agents use brand authority as a trust signal, and because human users will increasingly rely on brand familiarity to validate agent recommendations. The framework maps how brand authority translates into agent-mediated discovery, recommendation, and conversion.\n- **Components**: Agent Trust Signals (how does brand authority translate into signals that AI agents use to rank and recommend?), Human Validation Layer (how does brand familiarity help humans trust agent recommendations?), Brand-Agent Feedback Loop (strong brand → agent recommendation → user trust → purchase → stronger brand), Authority Accumulation (how is brand authority built in an agent-mediated world?), Vulnerability Assessment (what happens to weak brands when agents mediate discovery?)\n- **Apply**: (1) Assess your current brand authority: is it strong enough to serve as an agent trust signal? → (2) Map how AI agents currently perceive and rank your brand (reviews, structured data, institutional signals) → (3) Invest in the brand-agent feedback loop: strong brand → agent recommendations → user trust → purchase → stronger brand → (4) Build authority signals that agents recognize: consistent quality, verified credentials, positive user data → (5) For weak brands: the agent-mediated world is more dangerous — invest in brand building before agents fully mediate your market → (6) Brand is not just for humans anymore — it is infrastructure for the agentic web\n- **Key Q**: \"Is my brand strong enough to serve as a trust signal for AI agents — or will agent-mediated discovery render me invisible?\"", "sha256": "845fce3e30c2204c1883ac311693377d4a48b27420bfb509c304acb26cc1cf51", "sourceCategory": "XII. DISTRIBUTION & VISIBILITY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0098", "normalizedDefinition": "Authority may help an entity be selected by humans and agents, but its effect depends on retrieval, evidence, task and platform behavior.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Brand effects on agent recommendations are empirical and platform-dependent. More important is a hypothesis, not an automatic consequence of AI mediation." }, { "@id": "urn:business-engineer:source-entry:base:99", "@type": "SourceEntry", "id": "base:99", "sourceNumber": 99, "name": "AI Search Paradigm Shift", "body": "The fundamental transformation in how information discovery works, shifting from the traditional Crawl-Index-Rank model (search engines crawl the web, index content, and rank results by relevance signals) to the emerging Retrieve-Memory-Reason model (AI systems retrieve information from multiple sources, maintain contextual memory across sessions, and reason about the answer rather than listing links). This shift changes everything about visibility, content strategy, and digital distribution — the rules that governed discoverability for 25 years are being rewritten.\n- **Components**: Old Model — Crawl-Index-Rank (search engines crawl content, build indexes, rank by keyword relevance and authority signals), New Model — Retrieve-Memory-Reason (AI retrieves information, remembers context, reasons about answers), Visibility Implications (being cited by AI requires different signals than ranking in search results), Content Strategy Implications (content must be authoritative and comprehensive, not keyword-optimized), Distribution Implications (direct answers replace link lists — the click may never happen)\n- **Apply**: (1) Understand the shift: AI search does not list links — it provides answers derived from multiple sources → (2) Audit your content: is it optimized for keyword ranking (old model) or for being cited as an authoritative source (new model)? → (3) Invest in comprehensive, authoritative content that AI systems will choose to cite → (4) Build structured data that AI can retrieve and process → (5) Accept: in the new model, the user may never click through — your content must deliver value even when consumed by an AI intermediary → (6) Monitor AI citations: how often are AI systems referencing your content? → (7) This shift is not coming — it is here. Adapt now or lose discoverability\n- **Key Q**: \"Is my content and digital presence designed for the Crawl-Index-Rank world or the Retrieve-Memory-Reason world — and am I adapting fast enough?\"", "sha256": "418cc6fc2771e91ce73fa5ab8e5fb0dec06c1c5543fe1a05a59c106634b560eb", "sourceCategory": "XII. DISTRIBUTION & VISIBILITY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0099", "normalizedDefinition": "Evaluate how AI-mediated search changes discovery, referral and conversion using task-specific observations rather than a universal displacement claim.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "AI retrieval can still depend on crawling, indexing and ranking. Retrieve-Memory-Reason is a conceptual lens, not a universal replacement architecture or evidence that every system has persistent memory." }, { "@id": "urn:business-engineer:source-entry:base:100", "@type": "SourceEntry", "id": "base:100", "sourceNumber": 100, "name": "Bullseye Framework", "body": "A systematic method for finding the single best distribution channel from a universe of possible channels. Originally developed by Gabriel Weinberg and Justin Mares (Traction), and adopted into the BE toolkit for its structural rigor. The process: (1) Brainstorm all possible channels (19+ categories including SEO, content marketing, PR, paid ads, community, partnerships, etc.); (2) Rank by potential effectiveness for your specific business; (3) Test the top 3 with cheap, fast experiments; (4) Identify the Bullseye — the single channel that delivers the best results; (5) Double down on the Bullseye channel. The discipline is in focusing: most businesses spread resources across too many channels instead of dominating one.\n- **Components**: Channel Universe (all possible distribution channels — 19+ categories), Ranking Criteria (potential reach, cost, speed, fit with audience, competitive saturation), Top 3 Testing (cheap, fast experiments on the highest-potential channels), Bullseye Identification (the single channel that outperforms all others for your specific business), Concentration Discipline (doubling down on the Bullseye rather than spreading across many channels)\n- **Apply**: (1) List all possible distribution channels (content, SEO, paid ads, PR, partnerships, community, events, referrals, etc.) → (2) Rank by potential for your specific business and audience — not what works in general, but what works for you → (3) Select the top 3 and design cheap, fast tests for each → (4) Run the tests simultaneously with clear success metrics → (5) Identify the Bullseye: which channel delivered the best results relative to cost and effort? → (6) Concentrate resources on the Bullseye channel — dominate it before diversifying → (7) Revisit quarterly: the Bullseye can shift as the business grows and the market evolves\n- **Key Q**: \"Have I found my Bullseye distribution channel — or am I spreading resources across too many channels and dominating none?\"", "sha256": "3018fe12bdd80cb4b2057357d5cc140947f08d9954ca81f2cba16c9dd4036386", "sourceCategory": "XII. DISTRIBUTION & VISIBILITY", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0100", "normalizedDefinition": "Test multiple acquisition channels, concentrate on promising evidence and measure conversion economics before scaling a channel.", "evidence": "Use comparable cohorts and periods to connect acquisition, conversion, retention, price and contribution margin; separate traffic from demand.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:101", "@type": "SourceEntry", "id": "base:101", "sourceNumber": 101, "name": "Antifragility (Taleb)", "body": "The principle that some systems do not merely resist shocks — they gain from disorder, volatility, and stress. Nassim Nicholas Taleb's framework distinguishes three states: Fragile (breaks under stress), Robust (resists stress but doesn't improve), and Antifragile (gets stronger from stress). The BE applies this to organizations, strategies, and personal capability: the goal is not resilience (surviving shocks) but antifragility (becoming stronger because of shocks). This requires designing systems with optionality, redundancy, and exposure to small, survivable stresses.\n- **Components**: Fragile Systems (break under stress — centralized, over-optimized, brittle), Robust Systems (survive stress without improving — stable but static), Antifragile Systems (strengthen from stress — decentralized, optionality-rich, exposure to small shocks), Optionality (maintaining many small options rather than one large bet), Barbell Strategy (combine extreme safety with extreme risk, avoiding the middle)\n- **Apply**: (1) Assess your organization/strategy: is it fragile, robust, or antifragile? → (2) Reduce fragility: eliminate single points of failure, reduce over-optimization, build redundancy → (3) Build antifragility: create optionality (many small bets), expose the system to small stresses deliberately, design feedback loops that convert stress into learning → (4) Apply the barbell: keep 80-90% extremely safe while exposing 10-20% to extreme upside potential → (5) Embrace volatility: in an antifragile system, each shock is a training event, not a crisis\n- **Key Q**: \"Does my system get stronger from stress — or am I one shock away from breaking?\"", "sha256": "bd478e5e1338e7caac38e28a4d19882fe72647ba6e9261c9e79093778810efd0", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0101", "normalizedDefinition": "An antifragile system can benefit from some forms of variability or disorder within bounded exposure; this is distinct from merely surviving shocks.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Preserve Taleb’s attribution. Benefit from a bounded class of variability does not imply benefit from all shocks; specify exposure, survivability and the mechanism of improvement." }, { "@id": "urn:business-engineer:source-entry:base:102", "@type": "SourceEntry", "id": "base:102", "sourceNumber": 102, "name": "Day 1 Mentality (Bezos)", "body": "Jeff Bezos's operating philosophy that every day must feel like Day 1 of the company — characterized by urgency, customer obsession, experimental bias, and resistance to institutional calcification. Day 2, by contrast, is \"stasis, followed by irrelevance, followed by excruciating, painful decline, followed by death.\" The BE applies this as a diagnostic: when decision-making slows, when process replaces judgment, when the customer becomes an abstraction rather than an obsession, the organization has entered Day 2.\n- **Components**: Customer Obsession (decisions start and end with the customer, not the competitor or the process), High-Velocity Decision-Making (most decisions are reversible — make them quickly with 70% of the information you wish you had), Experimentation Bias (willingness to fail, willingness to be misunderstood for long periods), Process Skepticism (processes serve outcomes, not the reverse — when process becomes the proxy for outcome, you're on Day 2), External Focus (the outside world is always Day 1 — internal comfort is the enemy)\n- **Apply**: (1) Diagnose: is your organization on Day 1 or Day 2? → (2) Day 2 symptoms: slow decisions, process worship, customer as abstraction, internal focus, resistance to experimentation → (3) Restore Day 1 by re-centering on customer obsession: every meeting starts with \"what does the customer need?\" → (4) Accelerate decisions: adopt the 70% rule — decide with 70% of desired information, correct course later → (5) Reward experimentation and tolerate failure → (6) Attack process that has become proxy for outcomes → (7) Day 1 is not a state you reach — it is a discipline you maintain daily\n- **Key Q**: \"Are we on Day 1 or Day 2 — and what specific symptoms indicate which?\"", "sha256": "80fef858b69a1a40c8d5593a956bf9d1afedefee0628b0650253d4528b84fb8a", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0102", "normalizedDefinition": "Use a Day 1 orientation to sustain customer attention, experimentation and responsiveness while retaining operating discipline.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:103", "@type": "SourceEntry", "id": "base:103", "sourceNumber": 103, "name": "First Principles (Musk)", "body": "Elon Musk's reasoning methodology: instead of reasoning by analogy (what has worked before?), break problems down to their fundamental truths (what is physically/logically possible?) and reason up from there. First principles thinking is computationally expensive — it requires abandoning the comfort of convention and rebuilding understanding from base truths. The BE applies this selectively: for the most important strategic decisions, not for every daily choice. The power is in challenging assumptions that everyone else treats as fixed.\n- **Components**: Assumption Identification (what assumptions is everyone treating as fixed?), Decomposition (break the problem into its most fundamental components), Base Truth Validation (verify each component against physics, logic, or evidence — not convention), Reconstruction (rebuild the solution from validated base truths), Convention Challenge (the value is proportional to how many accepted assumptions you overturn)\n- **Apply**: (1) Select a strategic problem where conventional approaches have stalled → (2) List every assumption embedded in the conventional approach → (3) For each assumption, ask: is this physically/logically true, or is it just convention? → (4) Discard assumptions that are convention, keep those that are fundamental truths → (5) Rebuild the solution from the remaining base truths — this often produces radically different approaches → (6) Apply selectively: first principles thinking is expensive — reserve it for decisions where the payoff of challenging convention is highest → (7) The output should feel uncomfortable — if it feels familiar, you haven't gone deep enough\n- **Key Q**: \"Which assumptions am I treating as fixed that are actually just convention — and what happens when I reason from base truths instead?\"", "sha256": "64a2b4e77af8007b68e58904e351f9050532e3b95bb49fc5b5f160a6dad220a5", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0103", "normalizedDefinition": "Decompose a problem into defensible assumptions and constraints, then reconstruct alternatives rather than inheriting a conventional solution.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "First-principles reasoning predates Musk. The name in the source refers to a modern popularizer/application, not the originator of the method." }, { "@id": "urn:business-engineer:source-entry:base:104", "@type": "SourceEntry", "id": "base:104", "sourceNumber": 104, "name": "Value Investing (Buffett)", "body": "Warren Buffett's investment philosophy applied to strategic decision-making: seek assets (businesses, capabilities, positions) that are priced below their intrinsic value due to market sentiment, short-term thinking, or structural mispricing. The BE applies this beyond finance: to talent (undervalued people), markets (undervalued niches), technologies (undervalued capabilities), and strategies (approaches dismissed by the consensus that are structurally sound). The discipline is in patience, independent judgment, and the willingness to be wrong in the short term to be right in the long term.\n- **Components**: Intrinsic Value Assessment (what is the true, structural value — independent of market sentiment?), Margin of Safety (buy only when the price is significantly below intrinsic value), Long-Term Orientation (hold through short-term volatility when the thesis remains intact), Circle of Competence (invest only in areas you deeply understand), Contrarian Patience (willingness to wait, to be wrong in the short term, to look foolish until the thesis plays out)\n- **Apply**: (1) Develop an independent assessment of intrinsic value for the asset, opportunity, or strategy → (2) Compare to the market price or consensus view: is there a gap? → (3) Demand a margin of safety: don't invest unless the gap is significant → (4) Stay within your circle of competence: the value assessment is only as good as your understanding → (5) Be patient: intrinsic value and market price converge eventually, but timing is unpredictable → (6) Apply to non-financial decisions: undervalued talent, undervalued niches, undervalued strategies → (7) The discipline: buy when others are fearful, hold when others are impatient\n- **Key Q**: \"Is this opportunity priced below its intrinsic value — and do I have the patience and conviction to wait for convergence?\"", "sha256": "b0e3048a3f0f3a7f76b951e0c6df2e3ab70c648e8fe6f770d689d1ac51173645", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0104", "normalizedDefinition": "Compare price with a conservatively estimated range of intrinsic value while considering uncertainty, downside and the reliability of the valuation inputs.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Preserve Buffett’s association while recognizing the earlier value-investing tradition. Intrinsic value is uncertain and strategy should test assumptions rather than presume a true price." }, { "@id": "urn:business-engineer:source-entry:base:105", "@type": "SourceEntry", "id": "base:105", "sourceNumber": 105, "name": "Moonshot Thinking (Page)", "body": "Larry Page's philosophy of pursuing 10x improvements rather than 10% improvements. The counterintuitive insight: 10x goals are often easier to achieve than 10% goals because they force fundamentally different approaches — you cannot get to 10x by optimizing the existing system, so you are forced to reinvent. The BE applies this as a strategic reframing tool: when incremental optimization has stalled, restate the goal as 10x and observe how it changes the solution space from tweaks to reinvention.\n- **Components**: 10x Reframing (state the goal as 10x the current level — not incrementally better, but radically different), Solution Space Shift (10x goals make current approaches irrelevant, forcing new solution architectures), Constraint Breaking (10x goals reveal which constraints are real and which are assumed), Ambitious Talent Attraction (10x goals attract people who are bored by incremental work), Selective Application (not every problem deserves moonshot thinking — apply to the highest-leverage challenges)\n- **Apply**: (1) Identify a strategic challenge where incremental progress has stalled → (2) Restate the goal as 10x: if you needed to be 10x better, faster, or cheaper, what would change? → (3) Notice: the 10x framing immediately invalidates most current approaches → (4) Generate new approaches that could only work at 10x — these are usually more inventive and sometimes simpler → (5) Evaluate: which of these 10x approaches might actually work? → (6) Even if you achieve 5x instead of 10x, you've far exceeded what incremental optimization would have delivered → (7) Apply selectively: moonshot thinking is powerful but exhausting — reserve it for the highest-leverage problems\n- **Key Q**: \"If I needed 10x improvement instead of 10%, what approach would I take — and why am I not taking it?\"", "sha256": "304495b32a28fee606ce47b37fad3857c39f54261238ca367383dc47a21ab98f", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0105", "normalizedDefinition": "Pursue a large improvement by challenging limiting assumptions and testing feasibility; ambition alone does not justify the investment.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "A 10x target can expand the solution space, but is not generally easier than a 10% gain. Evaluate feasibility, resources and downside." }, { "@id": "urn:business-engineer:source-entry:base:106", "@type": "SourceEntry", "id": "base:106", "sourceNumber": 106, "name": "Zero to One (Thiel)", "body": "Peter Thiel's framework distinguishing between creating something genuinely new (0 to 1 — vertical innovation) and copying what works (1 to n — horizontal scaling). Zero to one is not about invention for its own sake — it is about finding the secret (something you believe is true that most people disagree with) and building a monopoly around it. The BE applies this as a strategic filter: is this business creating new value (0 to 1) or capturing existing value (1 to n)? The former creates lasting companies; the latter creates competition.\n- **Components**: Zero to One (vertical innovation — creating something the world has never seen), One to N (horizontal scaling — copying and distributing what already exists), The Secret (a truth you believe that most disagree with — the foundation of 0-to-1 companies), Monopoly Building (the goal is not competition but a category of one — where competition is irrelevant), Definite Optimism (the belief that the future is better AND that you can shape it through specific plans)\n- **Apply**: (1) Ask: is your business creating new value or redistributing existing value? → (2) If redistributing: you are in a 1-to-n business — expect competition and thin margins → (3) If creating: identify your secret — the insight that others believe is wrong → (4) Test the secret: if you tell smart people, do they disagree? If everyone agrees, it's not a secret → (5) Build a monopoly around the secret: dominate a small market completely before expanding → (6) Avoid competition: if you're competing, you're not doing 0-to-1 — find the space where competition is irrelevant → (7) The strategic test: are you building a company that the world doesn't yet know it needs?\n- **Key Q**: \"Am I creating genuinely new value (0 to 1) or competing for existing value (1 to n) — and what is my secret?\"", "sha256": "c4623b035fe3539fc57063edb58a9a50259faa4a07d0fd59a9a2504b3d0ac859", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0106", "normalizedDefinition": "Seek a distinct valuable capability or market position rather than assuming incremental competition is the only path to growth.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "New invention and adaptation can both create durable value; neither novelty nor a contrarian belief establishes a monopoly." }, { "@id": "urn:business-engineer:source-entry:base:107", "@type": "SourceEntry", "id": "base:107", "sourceNumber": 107, "name": "Blitzscaling (Hoffman)", "body": "Reid Hoffman's framework for prioritizing speed over efficiency in the face of uncertainty, specifically when network effects create winner-take-all dynamics. Blitzscaling is the deliberate decision to grow faster than comfortable, accepting inefficiency and higher burn rates because the cost of being too slow (losing the market to a competitor who scaled first) exceeds the cost of being too fast (wasted capital, organizational chaos). The BE applies this selectively: blitzscaling is correct in WTA markets with strong network effects, and catastrophic in markets without those conditions.\n- **Components**: Speed Over Efficiency (deliberately accepting operational chaos to grow faster), Winner-Take-All Conditions (blitzscaling is only correct when network effects create WTA dynamics), Acceptable Inefficiency (waste is the price of speed — budget for it), Competitive Timing (the window during which speed creates an insurmountable advantage), Exit Conditions (when to stop blitzscaling and shift to optimization)\n- **Apply**: (1) First, verify WTA conditions: does this market have strong network effects, high switching costs, and data returns to scale? → (2) If no: do NOT blitzscale — you'll burn capital without building defensible position → (3) If yes: assess the competitive window — how long before the market tips to a winner? → (4) During the window: prioritize speed over efficiency — accept higher costs, organizational chaos, and imperfect execution → (5) Measure: are you gaining market share faster than competitors? → (6) Set exit conditions: when the market has tipped (to you or against you), shift immediately from speed to efficiency → (7) The most common error: blitzscaling in markets that don't have WTA dynamics\n- **Key Q**: \"Does this market have winner-take-all dynamics that justify prioritizing speed over efficiency — or am I burning capital without building a defensible position?\"", "sha256": "9a17d6b001f51ab095ab2c3f4a198e8e5ffabcbe8a8f7cf50e2a87085644a50f", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0107", "normalizedDefinition": "Prioritize rapid scale under specific competitive conditions while explicitly accepting and monitoring the resulting inefficiency and risk.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Blitzscaling depends on financing capacity, market structure and survivable execution risks. It is not automatically correct whenever network effects exist." }, { "@id": "urn:business-engineer:source-entry:base:108", "@type": "SourceEntry", "id": "base:108", "sourceNumber": 108, "name": "Move Fast (Zuckerberg)", "body": "Mark Zuckerberg's operational philosophy — originally \"Move Fast and Break Things,\" later evolved to \"Move Fast with Stable Infrastructure\" — reflecting the principle that speed of iteration is the primary competitive advantage in technology markets. The BE applies this as a stage-dependent principle: in early stages, speed matters more than polish because the feedback from shipping is more valuable than the feedback from planning. As the system matures, speed must be maintained while adding stability — the art is in never losing speed even as complexity grows.\n- **Components**: Iteration Speed (how fast can you ship, measure, and learn?), Feedback Value (the insight gained from shipping exceeds the insight gained from planning), Stage Adaptation (early: speed > quality; growth: speed + quality; scale: speed + quality + stability), Speed Culture (organizational norms, tools, and incentives that preserve speed), Complexity Management (maintaining speed as organizational and product complexity grows)\n- **Apply**: (1) Measure your iteration speed: how long from idea to shipped product to measured outcome? → (2) If the cycle is weeks or months, it's too slow — find the bottleneck and eliminate it → (3) Early stage: prioritize speed ruthlessly — ship imperfect products, learn from real users → (4) Growth stage: add quality guardrails without sacrificing speed — automation, testing, CI/CD → (5) Scale stage: add stability infrastructure — but the moment speed drops, treat it as a crisis → (6) Build a speed culture: reward shipping, not planning; reward learning, not perfection → (7) The enemy is not failure — it is slowness\n- **Key Q**: \"How fast am I iterating — and what is the bottleneck preventing me from iterating faster?\"", "sha256": "2de67b18ac763e8e1f0d3525e5769e2aef2b967b52fddf35c0dabfba580721f5", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0108", "normalizedDefinition": "Increase learning speed through rapid iteration within boundaries appropriate to reversibility, user impact and operational risk.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:109", "@type": "SourceEntry", "id": "base:109", "sourceNumber": 109, "name": "Simplicity (Jobs)", "body": "Steve Jobs's design and strategic philosophy that simplicity is not the starting point but the destination — reached only after understanding a problem so deeply that you can strip away everything non-essential. Simplicity is not minimalism for its own sake; it is the result of obsessive focus on what matters and ruthless elimination of what doesn't. The BE applies this to analysis, products, and strategy: if you cannot express an insight simply, you do not understand it deeply enough. Complexity is a sign of incomplete thinking, not sophisticated thinking.\n- **Components**: Deep Understanding (simplicity requires deeper understanding than complexity — you must know what to cut), Ruthless Elimination (every element must justify its existence — if it doesn't add clear value, remove it), Focus as Strategy (saying no to a thousand things to say yes to one), User Experience Obsession (the user's experience is the final arbiter of simplicity), Iterative Refinement (simplicity is reached through many rounds of stripping away, not through initial design)\n- **Apply**: (1) Take any product, strategy, or analysis and ask: what can be removed without losing value? → (2) Remove it. Ask again. Repeat until removing anything would destroy value → (3) Test: can a new user/reader understand this without explanation? If not, simplify further → (4) Focus: what is the ONE thing this product/strategy/analysis must do brilliantly? Everything else is subordinate → (5) Resist the temptation to add: every new feature, element, or qualification is a cost to simplicity → (6) Simplicity is a competitive advantage: simpler products win because they're easier to use, explain, and spread → (7) If it's still complex, you don't understand it well enough yet\n- **Key Q**: \"What can I remove without losing value — and have I understood this deeply enough to make it simple?\"", "sha256": "ea32d353bac21e60db0e6d1380514c5465702b1172ae90986e976d49420e6447", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0109", "normalizedDefinition": "Reduce complexity in a product or decision while preserving the capabilities and distinctions its intended user needs.", "evidence": "State the competing explanations, record a prediction before observing the result, and seek an observation that would lead to a different decision.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Clarity is valuable, but some problems retain irreducible complexity. Compress language without deleting uncertainty or causal structure." }, { "@id": "urn:business-engineer:source-entry:base:110", "@type": "SourceEntry", "id": "base:110", "sourceNumber": 110, "name": "Customer Obsession (Bezos/Wilke)", "body": "The operating principle — championed by Jeff Bezos and operationalized by Jeff Wilke — that every decision begins and ends with the customer, not the competitor, not the shareholder, not the process. Customer obsession is distinct from customer focus: focus means considering the customer; obsession means the customer is the gravitational center around which everything orbits. The BE applies this as the ultimate tiebreaker: when two strategies seem equally valid, choose the one that is better for the customer — in the long run, this is always the winning bet.\n- **Components**: Customer as Starting Point (every initiative begins with the customer's need, not the company's capability), Working Backwards (start with the desired customer experience and work backward to the technology, process, and organization required), Long-Term Customer Value (optimize for lifetime customer relationship, not short-term extraction), Customer Signal Primacy (customer feedback, behavior, and complaints are the highest-priority data), Competitor Blindness (do not copy competitors — obsess over what the customer needs that no one is providing)\n- **Apply**: (1) For every initiative, start with: what does the customer need? Not what can we build, not what are competitors doing → (2) Work backward from the ideal customer experience to the required technology, process, and organization → (3) Optimize for long-term customer value: sacrifice short-term revenue for lifetime relationship when necessary → (4) Elevate customer signals: make customer feedback, complaints, and behavior data the most visible metrics in the organization → (5) Ignore competitors as the primary reference point — obsess over unmet customer needs → (6) The tiebreaker: when torn between options, choose the one that is better for the customer → (7) Customer obsession is not being nice — it is a strategic doctrine that compounds over decades\n- **Key Q**: \"Am I starting with the customer's need and working backward — or starting with my capabilities and hoping they match?\"", "sha256": "5719d2ad2398f12bcdff4396a77d55cd3f06d3694b9764f65a76a42ddbd87880", "sourceCategory": "XIII. LEADER MENTAL MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0110", "normalizedDefinition": "Use customer problems and observed behavior to guide priorities, while distinguishing expressed requests from underlying needs and viable economics.", "evidence": "Document substitutes, switching behavior, bargaining terms, customer value and the costs of sustaining or copying the claimed advantage.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Customer benefit is central but must coexist with economic sustainability and obligations to other stakeholders. It does not guarantee the winning strategy." }, { "@id": "urn:business-engineer:source-entry:base:111", "@type": "SourceEntry", "id": "base:111", "sourceNumber": 111, "name": "Revenue vs Depreciation, Not Revenue vs Capex", "body": "Comparing a buildout's annual revenue to its annual capex is a category error — capex buys an asset that produces revenue for years; revenue is a 12-month flow. No infrastructure build in history survives that ratio. The correct income-statement test is revenue against DEPRECIATION, which arrives on a fixed schedule regardless of whether revenue does.\n- **Key Q**: \"Is revenue covering the depreciation of what's already built — and is it growing faster than the depreciation wave that's coming?\"", "sha256": "12714622d7603d3093c1e59e373d80110a8422d1fc3c5887fd159115feb4856f", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0111", "normalizedDefinition": "Compare revenue with operating costs and depreciation for operating absorption; separately compare cash flows with capex for funding and investment returns.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Revenue and capex are both period flows. Capex/revenue is a valid capital-intensity ratio; it is not an investment-return test. Analyze revenue, operating costs and depreciation for profitability, capex and working capital for cash flow, and discounted future cash flows for capital returns." }, { "@id": "urn:business-engineer:source-entry:base:112", "@type": "SourceEntry", "id": "base:112", "sourceNumber": 112, "name": "The Hurdle Is Arithmetic", "body": "The revenue a capital program requires is not an opinion: `required revenue = capital deployed × (1/asset life + required return) ÷ gross margin`. Derive it, publish the sensitivity (asset life and gross margin are the highest-leverage variables), and compare independent derivations — when several methods converge, the hurdle is structural, not a scare figure.\n- **Key Q**: \"What revenue does the deployed capital arithmetically require — and what fraction of it exists today?\"", "sha256": "60e2fa871f769ade57f78a6dcd5af3afc6ca573882d1e0987d98b6b8334ff2fc", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0112", "normalizedDefinition": "Calculate the cash contribution needed to support invested capital under explicit timing, life, margin, return and salvage assumptions.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The supplied K × (1/n + r) ÷ margin is a rough capital-charge approximation, not an exact return hurdle. For a level end-of-year pre-tax cash-contribution stream and zero salvage, annual capital recovery is K × r/[1−(1+r)^(-n)], or K/n at r=0. Add relevant fixed cash costs and divide by a clearly defined cash-contribution margin; model taxes, ramp, working capital, replacements and residual value separately." }, { "@id": "urn:business-engineer:source-entry:base:113", "@type": "SourceEntry", "id": "base:113", "sourceNumber": 113, "name": "Allocation Becomes Obligation", "body": "A program funded from operating cash flow can be slowed at will; one funded by debt, leases, and external capital has counterparties, covenants, and maturities. When the CHARACTER of the money changes, a capital allocation decision becomes a credit cycle — even if nothing about the companies changed.\n- **Key Q**: \"Has the funding character changed from discretionary allocation to third-party obligation — and did anyone re-rate the risk when it did?\"", "sha256": "284b0f0b827a1a6d9957cd5715b2852525c408d4b98aff86cde36b22f8326368", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0113", "normalizedDefinition": "A planned capital allocation becomes an exposure as contractual commitments, construction and financing reduce the ability to cancel or redirect it.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Self-funded programs can still have binding purchase, lease and labor commitments. Funding source and contractual obligation are separate dimensions; neither external funding nor operating-cash-flow funding alone determines flexibility." }, { "@id": "urn:business-engineer:source-entry:base:114", "@type": "SourceEntry", "id": "base:114", "sourceNumber": 114, "name": "Absorption Capacity", "body": "Financing strain in a shared buildout is company-specific, not sector-wide. Each participant's position on the financial clock is set by its capital intensity (capex as a share of revenue and of operating cash flow) — one company self-funds with room while another cracks on the same build.\n- **Key Q**: \"What is this company's capital intensity — and where does that place it on the clock relative to peers running the same build?\"", "sha256": "105ffd350c3df729f7c2fd0c42c564edbdeeb10f23dfcd2ef4c3bde1dc57922b", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0114", "normalizedDefinition": "Measure whether an actor can carry a new obligation through operating earnings, cash generation, liquidity and funding access without conflating the tests.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:115", "@type": "SourceEntry", "id": "base:115", "sourceNumber": 115, "name": "Operating Absorption ≠ Cash Absorption", "body": "The income statement and the cash statement are two different tests and can give opposite answers inside one company: margins expanding while free cash flow goes negative. Run both. Strength on the operating line financed on the cash line is \"stretch from strength\" — a placement decision, not distress — but it is still stretch.\n- **Key Q**: \"Does the operating answer match the cash answer — and if not, which one is the market pricing?\"", "sha256": "f39198d15c19cca6c91b005982cd76d63a037a312d27b7399ee30bc18f0a5dc2", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0115", "normalizedDefinition": "Separate the operating capacity to bear depreciation and expenses from the cash capacity to fund investment, working capital and maturities.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "An operating/cash divergence is a diagnostic, not a verdict of strength or distress. Explain its sources, duration, commitments and available liquidity." }, { "@id": "urn:business-engineer:source-entry:base:116", "@type": "SourceEntry", "id": "base:116", "sourceNumber": 116, "name": "Net Income Has Two Engines", "body": "Reported net income mixes the operating engine with revaluation marks, equity gains, and other income. The operating line is the repeatable read; the marks are the headline risk. Strip the marks first in every print — especially when cross-holdings mean one relationship generates investment, commitment, and mark simultaneously.\n- **Key Q**: \"How much of the bottom line is the operating engine — and how much is a mark that can reverse?\"", "sha256": "ba3cfc338ce541768fc38c9c2e91d7d73bd9fb8362658c86da523be720889cab", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0116", "normalizedDefinition": "Separate operating performance from investment marks and other non-operating effects, reconciling positive and negative distortions to reported results.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:117", "@type": "SourceEntry", "id": "base:117", "sourceNumber": 117, "name": "Expensed vs Capitalized (The Control Group)", "body": "In any buildout, study the major player that opted out: it expenses what others capitalize, rents the input, and keeps the endpoint. No depreciation cliff, no stranded assets, no financial clock — the risk migrates into a contract instead of a balance sheet, and comes due later. The opt-out is the counterfactual that prices what building actually buys.\n- **Key Q**: \"What does the non-builder's position reveal about what the builders are paying for — and where did its risk go instead?\"", "sha256": "dcc676ee1c5158fa528582a10ee1b4923fefd09e416d484c43caac6dd9fddb17", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0117", "normalizedDefinition": "Distinguish costs recognized as expenses from expenditures capitalized and recognized over time; neither accounting treatment removes the economic cost.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Renting can reduce direct owned-asset exposure but does not remove financing risk. Leases, minimum commitments, guarantees, counterparty failure and loss of access may remain." }, { "@id": "urn:business-engineer:source-entry:base:118", "@type": "SourceEntry", "id": "base:118", "sourceNumber": 118, "name": "Pre-Funding Makes the Near Term Sticky", "body": "Capital already raised will be spent: bonds sold and facilities syndicated don't get cancelled with the plans they funded. Near-term capex is therefore sticky regardless of demand news — the real adjustment mechanism is NEXT year's guidance, which reveals a change of mind a full year before it appears in anyone's cash flow.\n- **Key Q**: \"Is this period's spend already funded and sticky — and am I watching guidance, where the actual decision will show first?\"", "sha256": "de729982ae3b4341539c541c5d66ea5b1d5451cfad170f023ff7551c0316c631", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0118", "normalizedDefinition": "Prefunding can lengthen a project's runway and make later spending more likely, but commitments, restrictions and cancellation rights determine durability.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Prefunding provides liquidity; it does not require the money to be spent. Stickiness depends on contracts, sunk costs, cancellation penalties, strategic incentives and alternative use of funds. Guidance is an indicator, not a guaranteed one-year lead." }, { "@id": "urn:business-engineer:source-entry:base:119", "@type": "SourceEntry", "id": "base:119", "sourceNumber": 119, "name": "Deferral vs Transfer", "body": "Off-balance-sheet obligations are not one thing: some are deferred (they land on the balance sheet eventually) and some are transferred (they never arrive — the risk lives in a vehicle, guarantee, or counterparty). Risk-weight them differently or the analysis destroys its own signal.\n- **Key Q**: \"Does this obligation eventually arrive on the balance sheet — or has the risk been moved somewhere it will never be consolidated?\"", "sha256": "0342b62ea0ad1010026635c265220a5ade95592148064052871fb5b4b28bd64e", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0119", "normalizedDefinition": "Deferring an obligation changes timing; transferring risk changes who bears it. Trace recourse, guarantees and retained exposure to distinguish the two.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Accounting non-consolidation does not prove economic risk transfer. Separate recognition timing, guarantees, recourse, first-loss exposure, legal transfer and residual incentives." }, { "@id": "urn:business-engineer:source-entry:base:120", "@type": "SourceEntry", "id": "base:120", "sourceNumber": 120, "name": "The Marginal Channel", "body": "The stock of financing tells you where a program has been; the marginal dollar tells you where it's going. The most diagnostic gauge in any financing analysis is whether the NEXT dollar is funded the same way as the last — off-book growth outpacing capex growth means the structure is changing at the margin even while the averages look sound.\n- **Key Q**: \"How is the marginal dollar financed — and is that different from how the average dollar was?\"", "sha256": "47fb9dab86408022a8d5a18f353099d2f395fcbd550e99e67dc2c3e822161d14", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0120", "normalizedDefinition": "Identify the next unit of funding and its terms, rather than inferring marginal financing conditions from the average historical capital mix.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Compare marginal funding using aligned periods and definitions. Faster off-book growth is a signal to inspect, not proof of concealment or a specific future cash burden." }, { "@id": "urn:business-engineer:source-entry:base:121", "@type": "SourceEntry", "id": "base:121", "sourceNumber": 121, "name": "The Credit Floor", "body": "Engineered financing structures work exactly as far down the credit ladder as investment grade reaches — and the boundary is observable: the deal that fails to place marks the floor's coordinates. Watch whether the structure stops at the floor or starts manufacturing credit quality synthetically (guarantees, wrappers) to extend below it.\n- **Key Q**: \"Where does investment grade end in this structure — and is anything being built to pretend it extends further?\"", "sha256": "580b2f6dbdaf0e92c94777cbc5a2e2e22e6bfc1bcd5d2be7431cc56900ceab6b", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0121", "normalizedDefinition": "Credit quality and contractual support can determine financing access and cost; there is no universal ratings cutoff or guaranteed credit floor.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Investment grade is not a universal financing boundary. Credit availability depends on cash flows, collateral, guarantees, covenants, pricing, liquidity and lender appetite." }, { "@id": "urn:business-engineer:source-entry:base:122", "@type": "SourceEntry", "id": "base:122", "sourceNumber": 122, "name": "The Amplifier, Not the Bubble", "body": "Financing fragility alone rarely produces a systemic break — stress every financing gauge and the composite still tops out below pre-break. The remaining distance is always the demand question. Financing structures are not the bubble; they are the amplifier a bubble would run through, and the honest instrument measures how much amplification has been installed.\n- **Key Q**: \"Am I measuring the probability of the shock — or the amplification installed for whenever the shock arrives?\"", "sha256": "79c77c90df5131a736d73fcc69949f85f759b1765a73a6f0542951b7dd84aeef", "sourceCategory": "XIV. CAPITAL CYCLES & FINANCING STRUCTURE (Compressed — apply via Phase 4 templates)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0122", "normalizedDefinition": "Financing can amplify shocks through leverage, collateral and refinancing needs; it is one possible mechanism in a broader demand and capital system.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Treat financing structure as an amplifier conditional on a shock. Demand, interest rates, refinancing access, collateral repricing and operational failure can all be shocks. No supplied calibration establishes a composite ceiling or pre-break probability." }, { "@id": "urn:business-engineer:source-entry:base:123", "@type": "SourceEntry", "id": "base:123", "sourceNumber": 123, "name": "The Layer Map Is Not the Credit Map", "body": "Value capture runs horizontally through an industry's layers; contagion runs vertically through the financing stack — different geometries over the same companies. A default doesn't propagate to the adjacent layer; it goes to whoever lent against it, whoever bought that paper, whoever holds the fund. Risk sits at the JOINTS between layers, not at a layer.\n- **Key Q**: \"Am I mapping where value lands or where losses travel — and have I located the joints where the two maps touch?\"", "sha256": "04ddac3b03e6764ab5c16360d2470a1a38c933b6e24bbf58aec2c5898f9f85c3", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0123", "normalizedDefinition": "A value-chain layer map does not reveal credit exposure. Build a separate map of contracts, guarantees, funding and counterparties.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Map actual contractual, financing and operational links. Horizontal and vertical are visualization conventions; losses can also propagate through shared inputs, sales dependencies and common asset holdings." }, { "@id": "urn:business-engineer:source-entry:base:124", "@type": "SourceEntry", "id": "base:124", "sourceNumber": 124, "name": "It Breaks Upward", "body": "Buildouts fail bottom-up: nothing fails at the strongest participant and cascades down — it fails at the weakest counterparty and travels UP through the lenders. Watching the top of the structure for the first crack is watching the wrong end. Early, small failures are cheap information: the structure disclosing its boundary while tuition is low.\n- **Key Q**: \"Where is the weakest counterparty in this structure — and what would its failure teach before anything expensive breaks?\"", "sha256": "c55d51e75582909dc3b99068638a7740d92924620e9e67a78aea21eabd32ecfa", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0124", "normalizedDefinition": "Trace how a shock propagates through contractual exposures; upward propagation is a case-specific hypothesis, not a required direction.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Weak counterparties can reveal stress early, but contagion can begin at any node, including a major platform, lender or shared infrastructure provider. Follow exposure direction and capacity to absorb loss; do not impose bottom-up causality." }, { "@id": "urn:business-engineer:source-entry:base:125", "@type": "SourceEntry", "id": "base:125", "sourceNumber": 125, "name": "The Sequencing Bet", "body": "Every leveraged buildout is a race between two calendars: when monetization must be demonstrated (the income statement) and when the debt must be refinanced (the maturity schedule). If the income statement answers before the maturity schedule asks, the refinancing wall never materializes — it was made of doubt, not arithmetic. If it disappoints, both failures arrive as one, through two channels.\n- **Key Q**: \"Which comes first here — the proof of monetization or the refinancing requirement — and what happens in each order?\"", "sha256": "7c28637acf524911c06169cc3079e1544216ece55d292e14860bc2a89a616cb4", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0125", "normalizedDefinition": "Test whether funding, construction, customer adoption and cash receipts arrive in a sequence the business can survive.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Monetization before maturity can improve refinancing prospects but does not remove debt maturities or guarantee access. Interest rates, liquidity, lender appetite and collateral still matter." }, { "@id": "urn:business-engineer:source-entry:base:126", "@type": "SourceEntry", "id": "base:126", "sourceNumber": 126, "name": "The Wrapper Trade", "body": "A guarantee converts the guarantor's credit into a derivative on the counterparty's. When a strong balance sheet backstops a weak counterparty's obligations, the market reprices the GUARANTOR on the counterparty's news — and a supplier guaranteeing its own customer's purchases has built circular exposure the layer map cannot show.\n- **Key Q**: \"Whose credit is actually being traded here — the issuer's, or the entity whose obligations it wrapped?\"", "sha256": "ce40f8dbd28161e0116b633a4a814463ff6ed4a454f6e66fe2b26a2d4982641c", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0126", "normalizedDefinition": "A financing wrapper can redistribute claims, maturity and risk without changing the underlying asset's operating productivity.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:127", "@type": "SourceEntry", "id": "base:127", "sourceNumber": 127, "name": "Downstream Incidence (The Bill for the Build)", "body": "A buildout's cost lands outside the builders too: wherever the bottleneck's inputs are shared, non-participants pay through input inflation, allocation loss, or channel taxes. Trace the incidence — the P&L of a company that builds nothing can be the cleanest read on how tight the build's constraint really is.\n- **Key Q**: \"Who is paying for this buildout without participating in it — and through which shared input does the bill arrive?\"", "sha256": "bd29358d598c312852dbedc925f0454fcbef745b080a3ad337c794f9265880fe", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0127", "normalizedDefinition": "Trace who ultimately bears a cost or captures a benefit through prices, contracts, substitutes and bargaining power, rather than only locating the initial payer.", "evidence": "Reconcile periods, units, accounting boundaries, operating cash flows, contractual obligations and downside funding requirements.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:128", "@type": "SourceEntry", "id": "base:128", "sourceNumber": 128, "name": "Price Is Not Capacity", "body": "When a constrained input inflates, a share of the headline investment number is a TRANSFER to the input's suppliers rather than an addition to capacity. Decompose spending growth into price and volume before reading it as expansion — one dollar in several may be paying more for the same thing.\n- **Key Q**: \"How much of this spending growth buys additional capacity — and how much just pays the new price of the old capacity?\"", "sha256": "f84fc6b3cd88169b64c9ad18ed2814937f97d632d0c89a7f6f00bebe30b59539", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0128", "normalizedDefinition": "Distinguish a quoted price from physically and contractually available capacity at the place, time and quality required.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:129", "@type": "SourceEntry", "id": "base:129", "sourceNumber": 129, "name": "Toll Booths vs Tourists", "body": "On any structurally constrained road, distinguish the toll booths (positions that price and ration the constraint — monopolies by physics or contract) from the tourists (positions that merely travel the road and pay). Watch for the sequel: the endpoint owner internalizes its most valuable tourist — integration converts a customer into a competitor.\n- **Key Q**: \"Does this company price the constraint or pay it — and can anyone upstream or downstream internalize its position?\"", "sha256": "d055502457697ab2d05ce6829cac8084d5f1a623907c84f86d02650b68a9fe5d", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0129", "normalizedDefinition": "A firm may earn durable rents from controlling a scarce junction, but access rents weaken when substitutes, capacity or bargaining conditions change.", "evidence": "Observe end-to-end throughput, decision rights, coordination, judgment quality and learning; compare task gains with firm-level outcomes.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "A bottleneck creates potential bargaining power only when the firm controls access and can capture rents. Substitution, contracts, regulation and customer integration may prevent monetization." }, { "@id": "urn:business-engineer:source-entry:base:130", "@type": "SourceEntry", "id": "base:130", "sourceNumber": 130, "name": "The Rotating Bottleneck", "body": "In a multi-input system, the binding constraint migrates as each is relieved — and late in a cycle two can bind at once. The current bottleneck sets today's pricing power; the NEXT bottleneck sets tomorrow's. Track the rotation, not the snapshot, and note that financing itself can join the rotation as a constraint.\n- **Key Q**: \"What binds today, what binds next — and is more than one constraint binding at once?\"", "sha256": "0557dd09d252b9824d4c97d40d159c8877af1d14d89994745cf2c851b11ff647", "sourceCategory": "XV. CONTAGION, INCIDENCE & JOINTS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0130", "normalizedDefinition": "The binding bottleneck can move as supply, efficiency, financing and adoption change; verify where the constraint binds at each decision horizon.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:131", "@type": "SourceEntry", "id": "base:131", "sourceNumber": 131, "name": "The Four Clocks", "body": "Any technology buildout runs on four unsynchronized clocks: PHYSICAL (years — committed capacity that cannot un-decide), FINANCIAL (quarters — engineered credit), EFFICIENCY (fastest — software absorbing physical constraint), ADOPTION (demand-side telemetry). Most cycle narratives fail by reading one clock as if it were the system. The bear and bull cases are usually claims about which clock dominates.\n- **Key Q**: \"Which clock is this datapoint on — and which clock is the argument I'm evaluating secretly assuming?\"", "sha256": "588d438ef07f51f26360c98cb396a3346915fb1ba2bd4d40188cbce69174e7d3", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0131", "normalizedDefinition": "Analyze asynchronous physical, financial, efficiency and adoption clocks, adding political objectives and permissions when state action materially changes the system.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "The four clocks are useful categories, not fixed speeds. Physical plans can be cancelled at a cost, credit may be committed for years, and efficiency or adoption can stall. Measure actual horizons and coupling." }, { "@id": "urn:business-engineer:source-entry:base:132", "@type": "SourceEntry", "id": "base:132", "sourceNumber": 132, "name": "Demand Has a Shape, Not Just a Size", "body": "Supply commits on long clocks against demand that moves on short ones — in SIZE (the macro cycle) and in SHAPE (where demand concentrates across the map). Every node's price is a bet that today's demand shape survives that node's build time; when the shape shifts, committed supply can't adjust, so price adjusts — locally and violently. A stack of coupled S-curves corrects node by node, not as one market.\n- **Key Q**: \"If demand keeps its size but changes its shape, which committed positions are stranded — and which quietly become the destination?\"", "sha256": "e0c6e0e49f10c0e1972eba491daa9c5a032967738c1422299206015a6aca55ce", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0132", "normalizedDefinition": "Map demand and investment by node, actor and time; a local correction does not by itself diagnose the condition of the entire buildout.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:133", "@type": "SourceEntry", "id": "base:133", "sourceNumber": 133, "name": "Split by Clock, Not by Category", "body": "Decompose any capital program by asset LIFE, not by line item: the short-lived share (fast-depreciating, hard to appraise, hostage to the next generation) and the long-lived share (appraisable, re-tenantable, financeable). The two halves of the same dollar have opposite exposures to the same event — and financing instruments built for one are routinely written against the other. That mismatch is where the risk hides.\n- **Key Q**: \"How does this spending split by asset clock — and is the financing matched to the clock it's actually secured against?\"", "sha256": "0b4df0d750354d5042bfc671022c554f0b730f5e8ac44b23e551a709d700de2e", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0133", "normalizedDefinition": "Separate exposures by the clocks that determine their adjustment, cash flow and repricing rather than assuming the whole stack moves together.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Apply as a context-dependent analytical heuristic. Establish relevant evidence, competing explanations and a decision horizon; the supplied description alone does not validate the model." }, { "@id": "urn:business-engineer:source-entry:base:134", "@type": "SourceEntry", "id": "base:134", "sourceNumber": 134, "name": "Efficiency Expands the Market (The Efficiency Paradox)", "body": "When a technology's unit cost collapses, total spend usually RISES — cheaper units expand use cases faster than they cut bills. But the same event is lethal to the SPECIFIC asset vintage it obsoletes: efficiency is bullish for the category and bearish for the collateral. Both are true at once; confusing them produces both bad bull and bad bear cases.\n- **Key Q**: \"Does this efficiency gain shrink the market or expand it — and which specific installed assets does it reprice on the way?\"", "sha256": "54d2f790f554041967d20c10432bc0aace1bd787eda5d9334406fe626433a214", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0134", "normalizedDefinition": "Efficiency can lower unit costs, alter demand and redistribute value; total spending and installed-asset returns depend on elasticity, pass-through and vintage exposure.", "evidence": "Date capacity, adoption, constraints, contracts and institutional changes; compare alternative supply or adoption paths and verify historical chronology.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Falling unit prices can increase quantity while total spending rises or falls. Spending rises only when the relevant quantity response outweighs the price decline. Separate workload demand, resource demand, supplier revenue and asset-vintage value; obsolescence is not automatic." }, { "@id": "urn:business-engineer:source-entry:base:135", "@type": "SourceEntry", "id": "base:135", "sourceNumber": 135, "name": "Own the Junctions, Rent the Ends (The Property Line)", "body": "In any stack, the ends commoditize and the junctions compound: models, tools, and capacity can be rented and swapped, but the routing points where private rules, data, and decisions are encoded should be owned. The most expensive position is the middle — renting everything while owning nothing that compounds. Draw the property line deliberately, per workload.\n- **Key Q**: \"Of everything this system touches, what compounds — and does it compound on my side of the property line or the vendor's?\"", "sha256": "1b4341b08bd41e1b090c8032995895240c94ebcbb380ed98d4f0ffeafb0165eb", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0135", "normalizedDefinition": "Decide which important junctions, knowledge and controls to own or contractually govern and which endpoints to rent, based on economics, rights and exit feasibility.", "evidence": "Inspect actual artifacts, rights, operating permissions, handovers and a priced alternative execution path; interviews alone do not establish control.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Own or control the junctions when their strategic value exceeds their costs and risks. Some endpoints compound, some junctions commoditize, and contractual rights may suffice. Make the boundary decision per workload." }, { "@id": "urn:business-engineer:source-entry:base:136", "@type": "SourceEntry", "id": "base:136", "sourceNumber": 136, "name": "Clear Title (KEPT / PARTIAL / CAPTURED)", "body": "For any dependency, grade each compounding artifact by its exit cost: KEPT (exit is a config change), PARTIAL (exit is a project), CAPTURED (exit is a rebuild — and rebuilds are where exit plans go to die). The closing question of any vendor engagement: after it ends, does the enterprise hold clear title to what compounds? Track the composite quarterly; dependency compounds in the dark.\n- **Key Q**: \"If this engagement ended tomorrow, what would exit actually cost, artifact by artifact — a config change, a project, or a rebuild?\"", "sha256": "d12b9230b87c3d1f73a8cde665113c07f7b565082affb8e5486511c2d9bb79a7", "sourceCategory": "XVI. CLOCKS, MAPS & DEPENDENCY (Compressed)", "sourceDocument": "urn:business-engineer:source-document:base", "canonicalModel": "urn:business-engineer:model:0136", "normalizedDefinition": "Assess retained rights, usable exports, semantic completeness, alternative execution and migration cost separately; operational exit readiness is not a legal title opinion.", "evidence": "Inspect actual artifacts, rights, operating permissions, handovers and a priced alternative execution path; interviews alone do not establish control.", "falsifier": "This is a selection or explanatory lens. Specify the case-level claim first; use evidence that distinguishes it from a rival explanation rather than treating the lens itself as a measured law.", "limits": "Separate legal rights, access to artifacts, semantic completeness, practical portability and economic switching cost. KEPT/PARTIAL/CAPTURED are operational exit grades; they do not establish legal title. Price and exercise the exit path." }, { "@id": "urn:business-engineer:source-entry:expansion:137", "@type": "SourceEntry", "id": "expansion:137", "sourceNumber": 137, "name": "Technology Constellation", "body": "Mechanism: A technology becomes economically transformative when complementary energy, materials, production, transport, capital and organizational capabilities reinforce one another. Map reciprocal enabling relationships rather than forcing a single invention-first story.\n\nUse When: Explain an industrial transition or identify which complement must develop before an AI capability can diffuse.\n\nEvidence: Identify what each complement makes cheaper, faster or feasible; date the enabling changes; compare places with the invention but without its complements.\n\nFalsifier: The claimed complement is absent in successful cases, or adoption follows another mechanism such as demand, institutions or distribution.\n\nDecision: Invest in or partner around the missing complement that limits a specific adoption path.\n\nLimits: A constellation is a causal hypothesis, not a universal sequence. Do not infer the chronology of coal, railways, iron, steel, naval power or oil from the diagram; verify it for each historical case.\n\nOrigin: Synthesis from the September 8, 2026 technogeopolitics discussion; linked to the general-purpose-technology literature, without claiming this formulation is validated by it.", "sha256": "4db7bbca63b89bef558830558fac58f0c346be322c1b2907ce147065cffa1664", "sourceCategory": "Technogeopolitics", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0137", "normalizedDefinition": "A technology becomes economically transformative when complementary energy, materials, production, transport, capital and organizational capabilities reinforce one another. Map reciprocal enabling relationships rather than forcing a single invention-first story.", "evidence": "Identify what each complement makes cheaper, faster or feasible; date the enabling changes; compare places with the invention but without its complements.", "falsifier": "The claimed complement is absent in successful cases, or adoption follows another mechanism such as demand, institutions or distribution.", "limits": "A constellation is a causal hypothesis, not a universal sequence. Do not infer the chronology of coal, railways, iron, steel, naval power or oil from the diagram; verify it for each historical case." }, { "@id": "urn:business-engineer:source-entry:expansion:138", "@type": "SourceEntry", "id": "expansion:138", "sourceNumber": 138, "name": "Capability-to-Power Conversion", "body": "Mechanism: Resource access creates potential. Production competence, reliable energy, logistics, finance, skilled institutions and deployment capacity determine whether potential becomes sustained economic or strategic power. Every conversion has losses and delays.\n\nUse When: Compare countries or firms that possess similar inputs but obtain different strategic outcomes.\n\nEvidence: Measure usable throughput, delivered cost, supply reliability, productive utilization, deployment reach and resilience. Locate the stage where an advantage stops translating.\n\nFalsifier: Input ownership alone predicts durable power better than conversion capability, or an omitted alliance or institutional variable explains the observed advantage.\n\nDecision: Strengthen the weakest conversion stage before acquiring more of an already abundant input.\n\nLimits: Economic capability does not mechanically produce military dominance, legitimacy or rule-making authority. Keep those outcomes separate and explain the intervening institutions.\n\nOrigin: Synthesis from the September 8, 2026 discussion of energy, industry, logistics and changing world power.", "sha256": "4c137d66d8d145e69acb43297da4fa2d552f9b2292d793fdb53f63d8b4b85a91", "sourceCategory": "Technogeopolitics", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0138", "normalizedDefinition": "Resource access creates potential. Production competence, reliable energy, logistics, finance, skilled institutions and deployment capacity determine whether potential becomes sustained economic or strategic power. Every conversion has losses and delays.", "evidence": "Measure usable throughput, delivered cost, supply reliability, productive utilization, deployment reach and resilience. Locate the stage where an advantage stops translating.", "falsifier": "Input ownership alone predicts durable power better than conversion capability, or an omitted alliance or institutional variable explains the observed advantage.", "limits": "Economic capability does not mechanically produce military dominance, legitimacy or rule-making authority. Keep those outcomes separate and explain the intervening institutions." }, { "@id": "urn:business-engineer:source-entry:expansion:139", "@type": "SourceEntry", "id": "expansion:139", "sourceNumber": 139, "name": "Legitimacy and Enforcement", "body": "Mechanism: An institutional order combines material capacity to enforce rules with participants’ reasons to accept them. Enforcement can sustain an unpopular order for a time; acceptance can reduce the cost of enforcement. Both feed back into resources and coalitions.\n\nUse When: Analyze the resilience of a geopolitical order, platform governance regime or industry standard.\n\nEvidence: Separate formal rules, actual compliance, enforcement capacity, perceived benefits, coalition cohesion and credible exit alternatives.\n\nFalsifier: Changes in legitimacy or enforcement do not alter compliance, or material incentives alone explain the pattern more convincingly.\n\nDecision: Identify whether the binding problem is enforcement, consent, distribution of benefits or a credible alternative institution.\n\nLimits: Do not infer that a power transition automatically ends international law or institutional legitimacy. Treat historical analogies as questions, not settled explanations.\n\nOrigin: Synthesis from the September 8, 2026 conversations about international order and technogeopolitics.", "sha256": "08b7bcfd7a3770b2e27bbf177b185479cb3e4c4f6d82c14dc8c18436b80035dc", "sourceCategory": "Technogeopolitics", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0139", "normalizedDefinition": "An institutional order combines material capacity to enforce rules with participants’ reasons to accept them. Enforcement can sustain an unpopular order for a time; acceptance can reduce the cost of enforcement. Both feed back into resources and coalitions.", "evidence": "Separate formal rules, actual compliance, enforcement capacity, perceived benefits, coalition cohesion and credible exit alternatives.", "falsifier": "Changes in legitimacy or enforcement do not alter compliance, or material incentives alone explain the pattern more convincingly.", "limits": "Do not infer that a power transition automatically ends international law or institutional legitimacy. Treat historical analogies as questions, not settled explanations." }, { "@id": "urn:business-engineer:source-entry:expansion:140", "@type": "SourceEntry", "id": "expansion:140", "sourceNumber": 140, "name": "Strategic Dependence Asymmetry", "body": "Mechanism: Dependence becomes leverage when one side can substitute, wait or absorb disruption more easily than the other. Supplier concentration matters through replacement time, usable alternatives, inventories, switching cost and exposure on both sides.\n\nUse When: Assess strategic autonomy, vendor dependency, supply-chain leverage or bargaining power.\n\nEvidence: For both parties, estimate replacement time, disruption loss over that time, inventories, alternative capacity and the credibility of threats.\n\nFalsifier: The apparently dependent party switches cheaply, the supplier suffers greater losses, or other actors can neutralize the pressure.\n\nDecision: Buy redundancy or switching capability where the asymmetry is consequential; avoid paying for nominal domestic ownership that does not improve usable alternatives.\n\nLimits: Nationality, ownership and control are different variables. Resilience can come from diversified interdependence rather than complete self-sufficiency.\n\nOrigin: Synthesis from sovereign-AI terminology, anti-lock-in and technogeopolitics discussions in August–September 2026.", "sha256": "0b801c0447de4c8dc73d04c6fcd1868911ca5c781b4536e686c3a6446475bf1c", "sourceCategory": "Technogeopolitics", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0140", "normalizedDefinition": "Dependence becomes leverage when one side can substitute, wait or absorb disruption more easily than the other. Supplier concentration matters through replacement time, usable alternatives, inventories, switching cost and exposure on both sides.", "evidence": "For both parties, estimate replacement time, disruption loss over that time, inventories, alternative capacity and the credibility of threats.", "falsifier": "The apparently dependent party switches cheaply, the supplier suffers greater losses, or other actors can neutralize the pressure.", "limits": "Nationality, ownership and control are different variables. Resilience can come from diversified interdependence rather than complete self-sufficiency." }, { "@id": "urn:business-engineer:source-entry:expansion:141", "@type": "SourceEntry", "id": "expansion:141", "sourceNumber": 141, "name": "Power Transition Lag", "body": "Mechanism: A new productive system can emerge before institutions, financing structures, skills and strategic doctrine adapt. The incumbent’s installed base may provide cash and reach while also creating commitments that slow adaptation.\n\nUse When: Assess transitions between industrial paradigms or between incumbent and AI-native operating models.\n\nEvidence: Track capability adoption and institutional adaptation separately; identify which legacy assets are reusable and which become constraints.\n\nFalsifier: The incumbent repurposes its assets faster than challengers build replacements, or the new capability fails to become economically significant.\n\nDecision: Preserve valuable inherited assets while changing the commitments that obstruct the new system.\n\nLimits: A lead in a technology does not date or guarantee a geopolitical succession. Fixed 30–50-year cycles are not forecasting laws.\n\nOrigin: Synthesis from technogeopolitics and technology-supercycle discussions; an analytical extension rather than a historical chronology.", "sha256": "bd2969e92b25df3c11473554960783fc3c27f16e224396ccedb30399dfa24c3a", "sourceCategory": "Technogeopolitics", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0141", "normalizedDefinition": "A new productive system can emerge before institutions, financing structures, skills and strategic doctrine adapt. The incumbent’s installed base may provide cash and reach while also creating commitments that slow adaptation.", "evidence": "Track capability adoption and institutional adaptation separately; identify which legacy assets are reusable and which become constraints.", "falsifier": "The incumbent repurposes its assets faster than challengers build replacements, or the new capability fails to become economically significant.", "limits": "A lead in a technology does not date or guarantee a geopolitical succession. Fixed 30–50-year cycles are not forecasting laws." }, { "@id": "urn:business-engineer:source-entry:expansion:142", "@type": "SourceEntry", "id": "expansion:142", "sourceNumber": 142, "name": "Computable Operating Model", "body": "Mechanism: Translate business concepts, desired outcomes, roles, decision rights, policies, process logic and exceptions into a maintained canonical representation. The representation makes organizational meaning inspectable before it is connected to execution.\n\nUse When: Scope enterprise AI work when operational knowledge is scattered across documents, systems, diagrams and people.\n\nEvidence: Trace representative decisions from source evidence to entities, policies, accountable owners and exceptions; have process owners validate the resulting interpretation.\n\nFalsifier: The model cannot represent material exceptions, owners cannot agree on meaning, or maintaining it costs more than the coordination it removes.\n\nDecision: Model a bounded process and its decision rights first, then connect the approved specification to an execution design.\n\nLimits: A representation is neither executable software nor proof of organizational agreement. Process-mining outputs are useful inputs, not a requirement to rebuild process mining.\n\nOrigin: User terminology from the WordLift computable-operating-model and Fixpoint conversations, August–September 2026.", "sha256": "56c7db7ae4d5842a67d0d28b19568bb370eee85ec9ce0420368bdfe2aac5a7e6", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0142", "normalizedDefinition": "Translate business concepts, desired outcomes, roles, decision rights, policies, process logic and exceptions into a maintained canonical representation. The representation makes organizational meaning inspectable before it is connected to execution.", "evidence": "Trace representative decisions from source evidence to entities, policies, accountable owners and exceptions; have process owners validate the resulting interpretation.", "falsifier": "The model cannot represent material exceptions, owners cannot agree on meaning, or maintaining it costs more than the coordination it removes.", "limits": "A representation is neither executable software nor proof of organizational agreement. Process-mining outputs are useful inputs, not a requirement to rebuild process mining." }, { "@id": "urn:business-engineer:source-entry:expansion:143", "@type": "SourceEntry", "id": "expansion:143", "sourceNumber": 143, "name": "Process Specification and Runtime", "body": "Mechanism: Separate the declarative process contract from the mechanism that executes it. A CPO records capabilities, boundaries, expected behavior and acceptance conditions; a runtime chooses and performs implementation steps within those constraints.\n\nUse When: Design a process product intended to work across models, agents or orchestration environments.\n\nEvidence: Map every required business invariant to a runtime control and an observable acceptance test. Run representative cases in more than one implementation when portability is claimed.\n\nFalsifier: Core business semantics depend on one runtime’s hidden state, or the specification cannot distinguish compliant from unacceptable outcomes.\n\nDecision: Stabilize the process contract and test alternative implementations against the same business requirements.\n\nLimits: CPO retains the user’s term without inventing its acronym expansion. Declarative design permits implementation freedom; it does not guarantee enforcement, reliability or zero-cost portability.\n\nOrigin: User refinement in Fixpoint discussions, September 3–8, 2026; design intent, not a claim of a completed interoperable standard.", "sha256": "5a5d6ae950656bf0c982126a3b2474a9ea65179cc3c1b47c7151c6476c4e510b", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0143", "normalizedDefinition": "Separate the declarative process contract from the mechanism that executes it. A CPO records capabilities, boundaries, expected behavior and acceptance conditions; a runtime chooses and performs implementation steps within those constraints.", "evidence": "Map every required business invariant to a runtime control and an observable acceptance test. Run representative cases in more than one implementation when portability is claimed.", "falsifier": "Core business semantics depend on one runtime’s hidden state, or the specification cannot distinguish compliant from unacceptable outcomes.", "limits": "CPO retains the user’s term without inventing its acronym expansion. Declarative design permits implementation freedom; it does not guarantee enforcement, reliability or zero-cost portability." }, { "@id": "urn:business-engineer:source-entry:expansion:144", "@type": "SourceEntry", "id": "expansion:144", "sourceNumber": 144, "name": "Reference Library and Customer Delta", "body": "Mechanism: Separate reusable process knowledge from the customer-specific rules, systems, terminology and exceptions that adapt it. Reuse can reduce deployment work only when the reference fits the new case and the delta remains governable.\n\nUse When: Design a repeatable enterprise offering around pre-seeded recipes and customer-owned process adaptations.\n\nEvidence: Record effort spent on reusable components, adaptation, integration, validation and ongoing maintenance for each deployment; record ownership and permission to reuse each artifact.\n\nFalsifier: Customer deltas repeatedly overwrite the reference, reuse requires confidential customer knowledge, or adaptation effort does not decline.\n\nDecision: Keep a versioned shared reference and a separately owned customer delta; use measured cohorts to decide where to standardize.\n\nLimits: The 80/20 split is a proposed design target, not a benchmark or measured outcome. Configuration size is not a proxy for effort, risk or value.\n\nOrigin: User distinction between platform-owned Recipe Library and client-owned Process Model, August–September 2026.", "sha256": "ebd8c23c6c867461362d1f52d314c58db700a7f46162685b72058089f5a80041", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0144", "normalizedDefinition": "Separate reusable process knowledge from the customer-specific rules, systems, terminology and exceptions that adapt it. Reuse can reduce deployment work only when the reference fits the new case and the delta remains governable.", "evidence": "Record effort spent on reusable components, adaptation, integration, validation and ongoing maintenance for each deployment; record ownership and permission to reuse each artifact.", "falsifier": "Customer deltas repeatedly overwrite the reference, reuse requires confidential customer knowledge, or adaptation effort does not decline.", "limits": "The 80/20 split is a proposed design target, not a benchmark or measured outcome. Configuration size is not a proxy for effort, risk or value." }, { "@id": "urn:business-engineer:source-entry:expansion:145", "@type": "SourceEntry", "id": "expansion:145", "sourceNumber": 145, "name": "N+1 Deployment Learning Curve", "body": "Mechanism: A deployment business becomes more product-like when knowledge from deployment N lowers the normalized effort or improves the outcomes of deployment N+1 without transferring restricted customer data.\n\nUse When: Evaluate whether a process platform can scale beyond bespoke implementation work.\n\nEvidence: Compare similar deployments by process complexity, integration burden and risk. Track calendar time, specialist hours, first-pass acceptance, exception rates and recurring support cost.\n\nFalsifier: Apparent improvement comes only from easier customers, unpaid labor, narrower scope or shifted maintenance costs.\n\nDecision: Scale the process families with demonstrated transfer; price or decline the work whose complexity remains customer-specific.\n\nLimits: A falling deployment-time chart alone does not establish a learning curve or a data moat. Normalize case mix and separate one-time delivery from recurring operation.\n\nOrigin: Synthesis of the Fixpoint N+1 deployment, pre-seeded expertise and productizing-the-deployment-layer discussions.", "sha256": "64cae17121bf8c0824ae72e48aaa48962ed78aeb542d52338aa6f04c1985b8c1", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0145", "normalizedDefinition": "A deployment business becomes more product-like when knowledge from deployment N lowers the normalized effort or improves the outcomes of deployment N+1 without transferring restricted customer data.", "evidence": "Compare similar deployments by process complexity, integration burden and risk. Track calendar time, specialist hours, first-pass acceptance, exception rates and recurring support cost.", "falsifier": "Apparent improvement comes only from easier customers, unpaid labor, narrower scope or shifted maintenance costs.", "limits": "A falling deployment-time chart alone does not establish a learning curve or a data moat. Normalize case mix and separate one-time delivery from recurring operation." }, { "@id": "urn:business-engineer:source-entry:expansion:146", "@type": "SourceEntry", "id": "expansion:146", "sourceNumber": 146, "name": "Semantic-to-Action Ladder", "body": "Mechanism: Machine-readable terminology helps identify meaning; entities and relationships supply context; capability and policy descriptions constrain available actions; authenticated execution changes state; evidence shows what actually happened. Each transition requires an explicit interface.\n\nUse When: Analyze agentic commerce or distinguish knowledge-graph value from workflow execution capability.\n\nEvidence: Trace one user intent through term resolution, entity grounding, applicable policy, authorized action, external state change and an observed outcome.\n\nFalsifier: Improved semantic coverage does not improve task success, or failures occur at unrelated execution or commercial constraints.\n\nDecision: Invest in the specific missing transition rather than treating additional markup as a complete agentic workflow.\n\nLimits: RDF, JSON-LD, schema markup and MCP do not by themselves grant business authority or guarantee transactions. The ladder is an analytical decomposition, not a mandatory software architecture.\n\nOrigin: User discussions on lexical graphs, action graphs, declarative APIs and WordLift semantic infrastructure, April–September 2026.", "sha256": "f8684c5a8eacde8e2a6ecaa9c7ad2cb74cc35606fc2bd4f7378541d97b689070", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0146", "normalizedDefinition": "Machine-readable terminology helps identify meaning; entities and relationships supply context; capability and policy descriptions constrain available actions; authenticated execution changes state; evidence shows what actually happened. Each transition requires an explicit interface.", "evidence": "Trace one user intent through term resolution, entity grounding, applicable policy, authorized action, external state change and an observed outcome.", "falsifier": "Improved semantic coverage does not improve task success, or failures occur at unrelated execution or commercial constraints.", "limits": "RDF, JSON-LD, schema markup and MCP do not by themselves grant business authority or guarantee transactions. The ladder is an analytical decomposition, not a mandatory software architecture." }, { "@id": "urn:business-engineer:source-entry:expansion:147", "@type": "SourceEntry", "id": "expansion:147", "sourceNumber": 147, "name": "Action Boundary Map", "body": "Mechanism: Assign each expected action to an operating boundary: owned, partner handoff, informational only or not applicable. Then identify the actor authorized to act, prerequisites, destination, observable result and escalation route.\n\nUse When: Review a machine-readable business capability or agent journey before treating it as executable.\n\nEvidence: Use current capability evidence, operating-owner confirmation, contracts or documented handoffs, permission checks and observed execution tests.\n\nFalsifier: The asserted owner cannot perform the action, a handoff destination is unverified, or a description is being mistaken for operational capability.\n\nDecision: Expose only the supported boundary and fix the missing ownership, handoff or execution evidence.\n\nLimits: User intent about a desired capability must not rewrite evidence-based readiness. Informational content can be valuable without being an executable action.\n\nOrigin: Exact boundary vocabulary from the September 4, 2026 Terms of Action review request.", "sha256": "05415fad3181cd873d9dc0be923a53a08be1cf3dfdabfa959fb95f534d6ab77a", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0147", "normalizedDefinition": "Assign each expected action to an operating boundary: owned, partner handoff, informational only or not applicable. Then identify the actor authorized to act, prerequisites, destination, observable result and escalation route.", "evidence": "Use current capability evidence, operating-owner confirmation, contracts or documented handoffs, permission checks and observed execution tests.", "falsifier": "The asserted owner cannot perform the action, a handoff destination is unverified, or a description is being mistaken for operational capability.", "limits": "User intent about a desired capability must not rewrite evidence-based readiness. Informational content can be valuable without being an executable action." }, { "@id": "urn:business-engineer:source-entry:expansion:148", "@type": "SourceEntry", "id": "expansion:148", "sourceNumber": 148, "name": "Portability Is Exercised", "body": "Mechanism: Portability exists in degrees: contractual rights, complete export, preserved meaning, alternative execution, acceptable performance and affordable migration. Evidence at one degree does not prove the others.\n\nUse When: Evaluate a vendor’s neutrality claim, a CPO design or an enterprise exit plan.\n\nEvidence: Exercise an export/import/replay on representative data and exceptions; price adapters, missing features, retraining, migration labor and downtime.\n\nFalsifier: The destination cannot reproduce required behavior or the practical exit cost remains comparable to a rebuild.\n\nDecision: Purchase and rehearse the specific switching option that matters for the workload; record residual dependencies explicitly.\n\nLimits: Owning a JSON file or using an open protocol is insufficient. Full interchangeability may be uneconomic; a bounded and priced exit can still be valuable.\n\nOrigin: Synthesis from CPO portability, Palantir/Databricks anti-lock-in and the Enterprise Capture Test discussions.", "sha256": "1595e71e218d8e23bafa1e2f9090d5a7b8e1ad2421c207e84f9ae5d40ae046c2", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0148", "normalizedDefinition": "Portability exists in degrees: contractual rights, complete export, preserved meaning, alternative execution, acceptable performance and affordable migration. Evidence at one degree does not prove the others.", "evidence": "Exercise an export/import/replay on representative data and exceptions; price adapters, missing features, retraining, migration labor and downtime.", "falsifier": "The destination cannot reproduce required behavior or the practical exit cost remains comparable to a rebuild.", "limits": "Owning a JSON file or using an open protocol is insufficient. Full interchangeability may be uneconomic; a bounded and priced exit can still be valuable." }, { "@id": "urn:business-engineer:source-entry:expansion:149", "@type": "SourceEntry", "id": "expansion:149", "sourceNumber": 149, "name": "Governance Independence Test", "body": "Mechanism: Governance is more independent when the party defining acceptance, holding evidence and authorizing exceptions can challenge the party optimizing execution. Structural independence depends on decision rights, incentives and access to evidence.\n\nUse When: Design oversight for interchangeable AI runtimes or evaluate a vendor’s assurance claim.\n\nEvidence: Identify who sets controls, changes tests, reports incidents, approves exceptions, can pause execution and receives commercial rewards.\n\nFalsifier: The overseer cannot inspect outcomes, alter approvals or escalate failures, or its compensation encourages hiding the same failures as the executor.\n\nDecision: Separate the necessary decision rights and evidence access; specify the conflicts that remain.\n\nLimits: A separate dashboard, company or model is not automatically independent. The third-party-CPA analogy describes a role and does not confer audit status or regulatory certification.\n\nOrigin: Synthesis from Fixpoint independent-governance and control-tower framing, September 2026.", "sha256": "6cfa6452aa2e0defc6439136a11e0ade54b41e5223e8e2ad05c8e8d429c1dd74", "sourceCategory": "Enterprise composability", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0149", "normalizedDefinition": "Governance is more independent when the party defining acceptance, holding evidence and authorizing exceptions can challenge the party optimizing execution. Structural independence depends on decision rights, incentives and access to evidence.", "evidence": "Identify who sets controls, changes tests, reports incidents, approves exceptions, can pause execution and receives commercial rewards.", "falsifier": "The overseer cannot inspect outcomes, alter approvals or escalate failures, or its compensation encourages hiding the same failures as the executor.", "limits": "A separate dashboard, company or model is not automatically independent. The third-party-CPA analogy describes a role and does not confer audit status or regulatory certification." }, { "@id": "urn:business-engineer:source-entry:expansion:150", "@type": "SourceEntry", "id": "expansion:150", "sourceNumber": 150, "name": "Regulated Process Wedge", "body": "Mechanism: A promising entry point is a specific process where costly recurring work, shared structure, an identifiable buyer and feasible delivery intersect. Regulatory load creates work; commercial value depends on who must do it, who pays and which steps can safely be standardized.\n\nUse When: Choose an initial enterprise process or compare niches for a process-automation platform.\n\nEvidence: Assess task frequency and complexity separately; verify budget, authority, repeatability, acceptable error, data access, liability allocation and precise existing alternatives.\n\nFalsifier: Mandatory work has no accessible budget, customers require mostly bespoke judgment, or a specific incumbent already solves the process economically.\n\nDecision: Advance a narrow paid design partnership only after delivery and buyer-access gates pass; then compare viable niches by economics and learning potential.\n\nLimits: Do not turn regulatory density into an automatic attractiveness score. Verify current laws, applicability and implementation dates for any real jurisdiction or process.\n\nOrigin: Synthesis from Fixpoint regulated-process market selection and SI distribution discussions, September 5–6, 2026.", "sha256": "5acfbdc2ab76ff17819440794da2e8d80774ec92cc8e4edcd4f41c7185777cb5", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0150", "normalizedDefinition": "A promising entry point is a specific process where costly recurring work, shared structure, an identifiable buyer and feasible delivery intersect. Regulatory load creates work; commercial value depends on who must do it, who pays and which steps can safely be standardized.", "evidence": "Assess task frequency and complexity separately; verify budget, authority, repeatability, acceptable error, data access, liability allocation and precise existing alternatives.", "falsifier": "Mandatory work has no accessible budget, customers require mostly bespoke judgment, or a specific incumbent already solves the process economically.", "limits": "Do not turn regulatory density into an automatic attractiveness score. Verify current laws, applicability and implementation dates for any real jurisdiction or process." }, { "@id": "urn:business-engineer:source-entry:expansion:151", "@type": "SourceEntry", "id": "expansion:151", "sourceNumber": 151, "name": "Partner Distribution Fit", "body": "Mechanism: A partner becomes a scalable channel when a proven process aligns with its reachable accounts, seller incentives, delivery capacity and customer relationship. An account list is potential access; active sellers and repeat deployments demonstrate distribution.\n\nUse When: Assess SI, consulting or technology partners for a repeatable enterprise offer.\n\nEvidence: Map eligible accounts to a process owner, named partner sponsor, seller compensation, joint offer, delivery team, procurement path and activated pipeline.\n\nFalsifier: The partner cannot name an economic buyer, seller incentives conflict, or the first deployments cannot be repeated without founder intervention.\n\nDecision: Co-design the first use case with the partner that can sell and deliver the next comparable deployment.\n\nLimits: Zero-to-50 deployments is an ambition, not a forecast. Do not multiply total partner customers by contract value and label the result revenue opportunity.\n\nOrigin: User partner-led market-entry and co-design proposal, September 2026.", "sha256": "6bcf0213ffe752b6f0b50842ba023b8db334c7fd412e3bbee4107decf864c6eb", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0151", "normalizedDefinition": "A partner becomes a scalable channel when a proven process aligns with its reachable accounts, seller incentives, delivery capacity and customer relationship. An account list is potential access; active sellers and repeat deployments demonstrate distribution.", "evidence": "Map eligible accounts to a process owner, named partner sponsor, seller compensation, joint offer, delivery team, procurement path and activated pipeline.", "falsifier": "The partner cannot name an economic buyer, seller incentives conflict, or the first deployments cannot be repeated without founder intervention.", "limits": "Zero-to-50 deployments is an ambition, not a forecast. Do not multiply total partner customers by contract value and label the result revenue opportunity." }, { "@id": "urn:business-engineer:source-entry:expansion:152", "@type": "SourceEntry", "id": "expansion:152", "sourceNumber": 152, "name": "Coopetition Boundary", "body": "Mechanism: A firm can be a channel at one layer, a competitor at another and a possible acquirer later. Map relationships around the exact process, artifact ownership, implementation role, customer access and renewal economics.\n\nUse When: Compare a process platform with SIs, forward-deployed AI companies or broad enterprise platforms.\n\nEvidence: Build a process-by-provider capability matrix using demonstrated capabilities; record who owns the customer, runtime, reusable knowledge, assurance and recurring contract.\n\nFalsifier: A presumed complementary partner already delivers the target process with superior economics, or the vendor’s expansion removes the partner’s incentive to distribute it.\n\nDecision: Draw a written commercial and capability boundary that leaves both sides a reason to repeat the deployment.\n\nLimits: A general AI platform does not prove strength in a narrow workflow; a narrow specialist is not automatically protected from a generalist. Potential acquisition is a scenario, not a distribution strategy.\n\nOrigin: Synthesis of Fixpoint versus Wonderful, SI enablement, channel conflict and possible SI acquisition discussions.", "sha256": "7a052c1dcda730d72fb3317e7f50e74b20a12c2ba2668561a4f11eca60c2a18c", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0152", "normalizedDefinition": "A firm can be a channel at one layer, a competitor at another and a possible acquirer later. Map relationships around the exact process, artifact ownership, implementation role, customer access and renewal economics.", "evidence": "Build a process-by-provider capability matrix using demonstrated capabilities; record who owns the customer, runtime, reusable knowledge, assurance and recurring contract.", "falsifier": "A presumed complementary partner already delivers the target process with superior economics, or the vendor’s expansion removes the partner’s incentive to distribute it.", "limits": "A general AI platform does not prove strength in a narrow workflow; a narrow specialist is not automatically protected from a generalist. Potential acquisition is a scenario, not a distribution strategy." }, { "@id": "urn:business-engineer:source-entry:expansion:153", "@type": "SourceEntry", "id": "expansion:153", "sourceNumber": 153, "name": "Deployment Bench Coverage", "body": "Mechanism: Enterprise delivery requires four functions to connect: Process Cartographer maps meaning and exceptions; Orchestration Architect integrates execution and controls; Value Engineer verifies outcomes and economics; Enterprise Partner secures adoption and commercial access.\n\nUse When: Assess whether a team can take a bounded process from discovery to reliable operation and renewal.\n\nEvidence: Assign a responsible person and a concrete deliverable to each function, then inspect the handoffs and missing skills.\n\nFalsifier: One function’s output is not usable by the next, or additional titles do not improve delivery outcomes.\n\nDecision: Fill the uncovered function or broken handoff before expanding headcount or sales commitments.\n\nLimits: These are coverage requirements, not four mandatory full-time hires. Preserve Process Cartographer as the user’s role name; do not replace it with Process Expert.\n\nOrigin: Exact four-role bench refined in the Fixpoint conversations, August–September 2026.", "sha256": "258cbb1b0198f0f81b0f8d94d427309789704cff45b04a1a847ba8ef0b1973b1", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0153", "normalizedDefinition": "Enterprise delivery needs coverage of process understanding, orchestration, outcome economics and adoption. Process Cartographer, Orchestration Architect, Value Engineer and Enterprise Partner are four specialist contributions; map them to lifecycle work and the five accountability functions without requiring four separate hires.", "evidence": "Inspect active work packages, required handoffs and actual authority; map the four specialist contributions to named accountable owners and independent acceptance.", "falsifier": "One function’s output is not usable by the next, or additional titles do not improve delivery outcomes.", "limits": "These are coverage requirements, not four mandatory full-time hires. Preserve Process Cartographer as the user’s role name; do not replace it with Process Expert." }, { "@id": "urn:business-engineer:source-entry:expansion:154", "@type": "SourceEntry", "id": "expansion:154", "sourceNumber": 154, "name": "Buyer Permission Path", "body": "Mechanism: An enterprise purchase crosses several decision rights: budget, business ownership, technical fit, security, legal terms, procurement and production acceptance. Progress at one gate does not imply progress at the others.\n\nUse When: Diagnose why strong demos and executive interest fail to become deployed, renewing business.\n\nEvidence: For each material gate, identify the decision owner, evidence needed, unresolved objection, dependency and expected timing.\n\nFalsifier: The proposed gating map cannot explain delays, or a different buying route removes the supposed veto.\n\nDecision: Resolve the gate currently constraining a specific account while preparing evidence for likely downstream gates.\n\nLimits: Not every enterprise has the same buying process. A PO evidences purchasing progress, not causal ROI, technical acceptance or permission for every production action.\n\nOrigin: Generalized from enterprise rollout and procurement discussions; private account names, prices and personnel are excluded.", "sha256": "e06127121d53a9d3ebf97f8bbabde00a91e07edaebdc880e9092d2d1390b8a24", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0154", "normalizedDefinition": "An enterprise purchase crosses several decision rights: budget, business ownership, technical fit, security, legal terms, procurement and production acceptance. Progress at one gate does not imply progress at the others.", "evidence": "For each material gate, identify the decision owner, evidence needed, unresolved objection, dependency and expected timing.", "falsifier": "The proposed gating map cannot explain delays, or a different buying route removes the supposed veto.", "limits": "Not every enterprise has the same buying process. A PO evidences purchasing progress, not causal ROI, technical acceptance or permission for every production action." }, { "@id": "urn:business-engineer:source-entry:expansion:155", "@type": "SourceEntry", "id": "expansion:155", "sourceNumber": 155, "name": "Product-to-Service Boundary", "body": "Mechanism: A recurring invoice can fund software, managed operation or repeated expert labor. Product economics depend on how revenue, delivery effort and recurring support change with the number and complexity of customers.\n\nUse When: Evaluate a run-layer business or test the claim that deployment is being productized.\n\nEvidence: Separate subscription, implementation and managed-service revenue; measure gross profit after deployment amortization, human review, support and maintenance by comparable customer cohort.\n\nFalsifier: Revenue grows only with proportional expert hours, or automation merely shifts labor into hidden support and exception queues.\n\nDecision: Productize common operating capability while pricing irreducible expert work transparently.\n\nLimits: Services can be valuable and profitable. Software, not hours is a positioning intention whose economics must be demonstrated; neither pricing label nor delivery speed proves it.\n\nOrigin: Synthesis from WordLift run-layer and Fixpoint deployment-layer positioning, August–September 2026.", "sha256": "f66c096b71bd2aa69041e171aae906ac4ee34828d405fb027e50d50a9242aa49", "sourceCategory": "Deployment and distribution", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0155", "normalizedDefinition": "A recurring invoice can fund software, managed operation or repeated expert labor. Product economics depend on how revenue, delivery effort and recurring support change with the number and complexity of customers.", "evidence": "Separate subscription, implementation and managed-service revenue; measure gross profit after deployment amortization, human review, support and maintenance by comparable customer cohort.", "falsifier": "Revenue grows only with proportional expert hours, or automation merely shifts labor into hidden support and exception queues.", "limits": "Services can be valuable and profitable. Software, not hours is a positioning intention whose economics must be demonstrated; neither pricing label nor delivery speed proves it." }, { "@id": "urn:business-engineer:source-entry:expansion:156", "@type": "SourceEntry", "id": "expansion:156", "sourceNumber": 156, "name": "Reliability Budget", "body": "Mechanism: End-to-end success depends on the entire path through grounding, decisions, tools, external systems, exceptions and recovery. Excellent local components can still produce unacceptable process outcomes.\n\nUse When: Evaluate an agent workflow or compare a compelling demo with a production commitment.\n\nEvidence: Measure accepted end-to-end completions, correlated failures, exception categories, recovery success, worst-case consequences and performance on representative difficult cases.\n\nFalsifier: Local failure estimates do not predict end-to-end failures, indicating shared causes, recovery effects or an incorrect process boundary.\n\nDecision: Spend engineering effort where a change most improves accepted outcomes under the required risk and latency constraints.\n\nLimits: The product of conditional step-success probabilities is a chain rule, not an independence claim. The shortcut p^n assumes identical independent steps and no recovery; label it illustrative and do not use it as measured reliability.\n\nOrigin: Synthesis from enterprise document extraction, machine vision, RCM reliability and harness discussions, August–September 2026.", "sha256": "083e4779acd862575632ccbce191110c291c762dd0341c581a42b5c50743d002", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0156", "normalizedDefinition": "End-to-end success depends on the entire path through grounding, decisions, tools, external systems, exceptions and recovery. Excellent local components can still produce unacceptable process outcomes.", "evidence": "Measure accepted end-to-end completions, correlated failures, exception categories, recovery success, worst-case consequences and performance on representative difficult cases.", "falsifier": "Local failure estimates do not predict end-to-end failures, indicating shared causes, recovery effects or an incorrect process boundary.", "limits": "The product of conditional step-success probabilities is a chain rule, not an independence claim. The shortcut p^n assumes identical independent steps and no recovery; label it illustrative and do not use it as measured reliability." }, { "@id": "urn:business-engineer:source-entry:expansion:157", "@type": "SourceEntry", "id": "expansion:157", "sourceNumber": 157, "name": "Cost per Accepted Outcome", "body": "Mechanism: Compare systems using total attributable cost divided by accepted outcomes over a stated period. Include inference, tools, retries, review, recovery, support and an explicit treatment of deployment cost.\n\nUse When: Choose models or runtimes, evaluate outcome pricing, or test whether automation improves economics.\n\nEvidence: Define acceptance before measurement; report quality, throughput, latency and failure consequences beside cost. Use the same case mix and period for comparisons.\n\nFalsifier: A cheaper result fails acceptance, imposes larger downstream losses, or benefits from omitted labor and shifted costs.\n\nDecision: Select the configuration that meets outcome requirements at the best supported economics; expose the quality-cost tradeoff.\n\nLimits: Cost per outcome is undefined with no accepted outcomes. Separate marginal and fully loaded views; avoid counting the same review cost twice or valuing all outcomes identically when their stakes differ.\n\nOrigin: Synthesis from model routing limits, control-tower metrics and outcome-pricing discussions.", "sha256": "3d6eb388f3ce28ab472905ed6eca1744d86480aac7033230d28999c0f4291415", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0157", "normalizedDefinition": "Compare systems using total attributable cost divided by accepted outcomes over a stated period. Include inference, tools, retries, review, recovery, support and an explicit treatment of deployment cost.", "evidence": "Define acceptance before measurement; report quality, throughput, latency and failure consequences beside cost. Use the same case mix and period for comparisons.", "falsifier": "A cheaper result fails acceptance, imposes larger downstream losses, or benefits from omitted labor and shifted costs.", "limits": "Cost per outcome is undefined with no accepted outcomes. Separate marginal and fully loaded views; avoid counting the same review cost twice or valuing all outcomes identically when their stakes differ." }, { "@id": "urn:business-engineer:source-entry:expansion:158", "@type": "SourceEntry", "id": "expansion:158", "sourceNumber": 158, "name": "Evidence-to-Value Chain", "body": "Mechanism: Track five distinct claims: an intervention was delivered; behavior changed; an operational outcome improved; the improvement was attributable; economic value was realized. A dashboard observation cannot automatically jump to the last claim.\n\nUse When: Evaluate enterprise AI pilots, AI visibility programs or benefits claimed from process deployment.\n\nEvidence: Specify baseline, counterfactual, exposure, measurement period and confounders; connect the operational result to an agreed economic conversion and verify realized value.\n\nFalsifier: A credible comparison explains the outcome without the intervention, the effect disappears under case-mix controls, or the claimed economic conversion does not occur.\n\nDecision: Fund the next step based on the strongest supported claim and design the cheapest credible test for the next link.\n\nLimits: Before-and-after movement, correlations, citations and prompt visibility are not automatically causal revenue effects. Distinguish estimated, realized and attributable savings.\n\nOrigin: Generalized from WordLift measurement and Fixpoint Value Engineer discussions; no private client results are reproduced.", "sha256": "02fc4e76e827cb4e3a76cb00fbc2c0354292f1ecb1d3fe87acff404e62485bca", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0158", "normalizedDefinition": "Track five distinct claims: an intervention was delivered; behavior changed; an operational outcome improved; the improvement was attributable; economic value was realized. A dashboard observation cannot automatically jump to the last claim.", "evidence": "Specify baseline, counterfactual, exposure, measurement period and confounders; connect the operational result to an agreed economic conversion and verify realized value.", "falsifier": "A credible comparison explains the outcome without the intervention, the effect disappears under case-mix controls, or the claimed economic conversion does not occur.", "limits": "Before-and-after movement, correlations, citations and prompt visibility are not automatically causal revenue effects. Distinguish estimated, realized and attributable savings." }, { "@id": "urn:business-engineer:source-entry:expansion:159", "@type": "SourceEntry", "id": "expansion:159", "sourceNumber": 159, "name": "Incentive Compatibility Map", "body": "Mechanism: An efficiency gain creates different gains and losses for the buyer, operator, seller, partner and risk owner. Adoption becomes easier when decision rights, compensation and ownership reward the behavior required for the system to work.\n\nUse When: Explain resistance to automation, channel conflict or governance that looks strong on paper.\n\nEvidence: For each actor, map benefits, displaced revenue or work, new liability, required behavior, decision power and compensation.\n\nFalsifier: Behavior remains unchanged after the proposed incentive adjustment, suggesting capability, trust, identity or a different constraint dominates.\n\nDecision: Change the commercial or organizational arrangement so the actors needed for adoption can benefit from successful operation.\n\nLimits: Do not infer motives as facts or assume resistance is irrational. Incentive alignment does not remove capability or ethical constraints.\n\nOrigin: Synthesis from SI hours versus outcome economics, enterprise adoption and independent governance conversations.", "sha256": "f10ad084a6719b60d0bdbb8b0502cff9c2691619735a0f3981d503607761e2c2", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0159", "normalizedDefinition": "An efficiency gain creates different gains and losses for the buyer, operator, seller, partner and risk owner. Adoption becomes easier when decision rights, compensation and ownership reward the behavior required for the system to work.", "evidence": "For each actor, map benefits, displaced revenue or work, new liability, required behavior, decision power and compensation.", "falsifier": "Behavior remains unchanged after the proposed incentive adjustment, suggesting capability, trust, identity or a different constraint dominates.", "limits": "Do not infer motives as facts or assume resistance is irrational. Incentive alignment does not remove capability or ethical constraints." }, { "@id": "urn:business-engineer:source-entry:expansion:160", "@type": "SourceEntry", "id": "expansion:160", "sourceNumber": 160, "name": "Autonomy Envelope", "body": "Mechanism: Define the bounded conditions under which a system may act without additional human review: allowed entities, action types, scope, financial limits, evidence, reversibility, monitoring and escalation. The envelope can expand only as evidence and authority permit.\n\nUse When: Move a bounded agent process from assisted work toward greater autonomy.\n\nEvidence: Exercise allowed and forbidden cases, approval triggers, rollback, monitoring coverage and escalation; verify that the authorized owner accepts the residual risk.\n\nFalsifier: The system cannot detect when it leaves the envelope, overrides are untraceable, or apparent success depends on constant unrecorded human rescue.\n\nDecision: Grant autonomy to a well-observed subset of the process and retain review at the boundaries that are consequential or uncertain.\n\nLimits: Model confidence alone is insufficient. Technical capability, organizational authority and acceptable risk are separate conditions; do not infer permission from an interface description.\n\nOrigin: Synthesis from Terms of Action, CPO boundaries and enterprise governance discussions.", "sha256": "0dbad0bbcae9e85476523911048ccb4a44863bd3fddd9286fb67aa91e9565ab4", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0160", "normalizedDefinition": "Define the bounded conditions under which a system may act without additional human review: allowed entities, action types, scope, financial limits, evidence, reversibility, monitoring and escalation. The envelope can expand only as evidence and authority permit.", "evidence": "Exercise allowed and forbidden cases, approval triggers, rollback, monitoring coverage and escalation; verify that the authorized owner accepts the residual risk.", "falsifier": "The system cannot detect when it leaves the envelope, overrides are untraceable, or apparent success depends on constant unrecorded human rescue.", "limits": "Model confidence alone is insufficient. Technical capability, organizational authority and acceptable risk are separate conditions; do not infer permission from an interface description." }, { "@id": "urn:business-engineer:source-entry:expansion:161", "@type": "SourceEntry", "id": "expansion:161", "sourceNumber": 161, "name": "Maintenance Burden Map", "body": "Mechanism: Operating burden depends on how often requirements change, how difficult each change is and how widely it propagates. Regulation is one source alongside data drift, integrations, model changes and organizational ownership.\n\nUse When: Compare process niches or budget the ongoing cost of maintaining a governed deployment.\n\nEvidence: Track update frequency, specialist effort per update, affected dependencies, revalidation time, service impact and backlog age separately.\n\nFalsifier: High nominal regulatory complexity generates little actual maintenance, or a low-regulation process changes more expensively through integration churn.\n\nDecision: Choose and price processes using observed maintenance economics; automate reusable checks and assign ownership for each change source.\n\nLimits: A frequency-by-complexity matrix supports comparison, not an empirically calibrated universal score. Regulatory obligations, effective dates and applicability require current primary-source verification.\n\nOrigin: User request to map regulatory frequency and complexity for Fixpoint, September 6, 2026; broadened to total operating maintenance.", "sha256": "6b7f6c46d2eaf744a4c29f9d2d1604d10ce031974e6f7ba251716f01f9980404", "sourceCategory": "Outcomes and governance", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0161", "normalizedDefinition": "Operating burden depends on how often requirements change, how difficult each change is and how widely it propagates. Regulation is one source alongside data drift, integrations, model changes and organizational ownership.", "evidence": "Track update frequency, specialist effort per update, affected dependencies, revalidation time, service impact and backlog age separately.", "falsifier": "High nominal regulatory complexity generates little actual maintenance, or a low-regulation process changes more expensively through integration churn.", "limits": "A frequency-by-complexity matrix supports comparison, not an empirically calibrated universal score. Regulatory obligations, effective dates and applicability require current primary-source verification." }, { "@id": "urn:business-engineer:source-entry:expansion:162", "@type": "SourceEntry", "id": "expansion:162", "sourceNumber": 162, "name": "Counter-Model Pairing", "body": "Mechanism: Select a causal explanation, an economic consequence and the strongest plausible competing explanation. The purpose of multiple models is to expose different assumptions, not to create several votes for the same story.\n\nUse When: Analyze a high-conviction strategic thesis or any case where familiar frameworks all seem to agree.\n\nEvidence: List shared premises, identify a discriminating observation and state what each explanation predicts differently.\n\nFalsifier: The models produce the same observable predictions or rely on the same evidence; the apparent comparison adds no independent information.\n\nDecision: Collect evidence that can choose between explanations, and reduce confidence when the current evidence cannot discriminate.\n\nLimits: More frameworks do not create independent confirmation. A competing model must be plausible and decision-relevant, not a straw man.\n\nOrigin: Methodological extension to the supplied BIA; motivated by repeated requests to check claims and avoid purely rhetorical contrarianism.", "sha256": "dd33784bd7e011f16032ae527a43ec685b8d69b7dab79065597a5e179ffe80aa", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0162", "normalizedDefinition": "Select a causal explanation, an economic consequence and the strongest plausible competing explanation. The purpose of multiple models is to expose different assumptions, not to create several votes for the same story.", "evidence": "List shared premises, identify a discriminating observation and state what each explanation predicts differently.", "falsifier": "The models produce the same observable predictions or rely on the same evidence; the apparent comparison adds no independent information.", "limits": "More frameworks do not create independent confirmation. A competing model must be plausible and decision-relevant, not a straw man." }, { "@id": "urn:business-engineer:source-entry:expansion:163", "@type": "SourceEntry", "id": "expansion:163", "sourceNumber": 163, "name": "Assumption and Prediction Ledger", "body": "Mechanism: Separate what is observed, assumed, inferred and predicted. Record the evidence and confidence behind material claims, then return to time-bounded predictions to see which reasoning actually worked.\n\nUse When: Maintain a thesis across earnings prints, pilots, partner discussions or technology transitions.\n\nEvidence: For each material claim retain an as-of date, source, assumption, observable prediction, decision dependency, review trigger and outcome when resolved.\n\nFalsifier: Predictions are too vague to score, definitions shift after the fact, or confidence does not change after contrary observations.\n\nDecision: Revise the claim, model choice or action when discriminating evidence arrives; retain the reason for the change.\n\nLimits: Numerical probabilities require a coherent basis and enough comparable resolved forecasts to evaluate calibration. A narrative confidence label is not statistical calibration.\n\nOrigin: Extension of the supplied calibration loop, layered-map season method and editorial evidence discipline.", "sha256": "f14cf6449dd7d796ae378a16e61b4fc6fa03645c2be315d29455c8226b6ebeda", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0163", "normalizedDefinition": "Separate what is observed, assumed, inferred and predicted. Record the evidence and confidence behind material claims, then return to time-bounded predictions to see which reasoning actually worked.", "evidence": "For each material claim retain an as-of date, source, assumption, observable prediction, decision dependency, review trigger and outcome when resolved.", "falsifier": "Predictions are too vague to score, definitions shift after the fact, or confidence does not change after contrary observations.", "limits": "Numerical probabilities require a coherent basis and enough comparable resolved forecasts to evaluate calibration. A narrative confidence label is not statistical calibration." }, { "@id": "urn:business-engineer:source-entry:expansion:164", "@type": "SourceEntry", "id": "expansion:164", "sourceNumber": 164, "name": "Regime-Switch Trigger", "body": "Mechanism: A strategy can remain coherent while the conditions that justify it change. Define observations that move the response from monitoring to reallocation to existential response, together with observations that permit de-escalation.\n\nUse When: Monitor competitive threats, adoption disappointments or changes in a capital-cycle thesis.\n\nEvidence: Specify the mechanism expected to change, the observable trigger, confirmation requirements, decision owner and response cost.\n\nFalsifier: Triggers fire frequently without the predicted regime change, or the response ignores evidence that the threat has receded.\n\nDecision: Pre-agree proportionate actions for genuinely different states and revise triggers after false alarms.\n\nLimits: Code Yellow, Orange and Red are optional labels, not calibrated risk categories. Avoid treating ordinary volatility as a regime switch.\n\nOrigin: Formalizes a prior assistant-proposed Graduated Strategic Threat Response from December 13, 2025; retained as an unvalidated heuristic.", "sha256": "9eefab11becb81ddf8a7620353e5515f1527b16838e0ef47ccca592eb401f857", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0164", "normalizedDefinition": "A strategy can remain coherent while the conditions that justify it change. Define observations that move the response from monitoring to reallocation to existential response, together with observations that permit de-escalation.", "evidence": "Specify the mechanism expected to change, the observable trigger, confirmation requirements, decision owner and response cost.", "falsifier": "Triggers fire frequently without the predicted regime change, or the response ignores evidence that the threat has receded.", "limits": "Code Yellow, Orange and Red are optional labels, not calibrated risk categories. Avoid treating ordinary volatility as a regime switch." }, { "@id": "urn:business-engineer:source-entry:expansion:165", "@type": "SourceEntry", "id": "expansion:165", "sourceNumber": 165, "name": "Decision-Changing Information", "body": "Mechanism: Research has value when a feasible result could change the chosen action enough to justify the cost, delay and distraction of obtaining it. Uncertainty that cannot change the decision need not be resolved first.\n\nUse When: Choose the next diligence task, experiment or customer interview under time constraints.\n\nEvidence: State the current best action, the uncertain assumption, plausible results and how each result would change the action.\n\nFalsifier: Every plausible result leaves the decision unchanged, or collecting the information costs more than the expected improvement in the decision.\n\nDecision: Run the smallest credible test of the assumption with the greatest decision consequence; otherwise act or wait deliberately.\n\nLimits: Do not fabricate probabilities to manufacture a value-of-information number. Irreversible or high-consequence decisions may justify more diligence even when uncertainty remains.\n\nOrigin: Decision-theory extension of Act vs Wait and the user’s preference for precise, actionable analysis.", "sha256": "5be45f4a257b328dfca1f6cd653dafc09931e6deaf20e64ea15ec13bc03a37ce", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0165", "normalizedDefinition": "Research has value when a feasible result could change the chosen action enough to justify the cost, delay and distraction of obtaining it. Uncertainty that cannot change the decision need not be resolved first.", "evidence": "State the current best action, the uncertain assumption, plausible results and how each result would change the action.", "falsifier": "Every plausible result leaves the decision unchanged, or collecting the information costs more than the expected improvement in the decision.", "limits": "Do not fabricate probabilities to manufacture a value-of-information number. Irreversible or high-consequence decisions may justify more diligence even when uncertainty remains." }, { "@id": "urn:business-engineer:source-entry:expansion:166", "@type": "SourceEntry", "id": "expansion:166", "sourceNumber": 166, "name": "Goldilocks Embedding", "body": "Mechanism: A deeply embedded provider can remain durable when it continues to create value, leaves the customer enough surplus and keeps its charges within a range the customer considers justified. Dependence without continuing value increases incentives to exit or sponsor substitutes.\n\nUse When: Evaluate platform extraction, run-layer pricing or whether strong switching costs are becoming a commercial liability.\n\nEvidence: Track realized customer benefit, full cost of use, price changes, renewal behavior, complaints, substitution efforts and the cost of exit.\n\nFalsifier: Customer surplus remains healthy but retention falls for another reason, or extraction does not create credible switching incentives in the relevant period.\n\nDecision: Price around continuing value and invest in improvements that make staying worthwhile; distinguish retention by value from retention by obstruction.\n\nLimits: The prior V/E bands above 2, between 1 and 2, and below 1 were illustrative, not validated cutoffs. Benefit estimates and price changes are often too noisy for a precise universal ratio.\n\nOrigin: Refines prior assistant-proposed Goldilocks Embedding from December 13, 2025; not represented as a published empirical law.", "sha256": "0292937ec7cd32c29e0b14dc49595cc2df0953d7bb1dbdf56199ae15b2826141", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0166", "normalizedDefinition": "A deeply embedded provider can remain durable when it continues to create value, leaves the customer enough surplus and keeps its charges within a range the customer considers justified. Dependence without continuing value increases incentives to exit or sponsor substitutes.", "evidence": "Track realized customer benefit, full cost of use, price changes, renewal behavior, complaints, substitution efforts and the cost of exit.", "falsifier": "Customer surplus remains healthy but retention falls for another reason, or extraction does not create credible switching incentives in the relevant period.", "limits": "The prior V/E bands above 2, between 1 and 2, and below 1 were illustrative, not validated cutoffs. Benefit estimates and price changes are often too noisy for a precise universal ratio." }, { "@id": "urn:business-engineer:source-entry:expansion:167", "@type": "SourceEntry", "id": "expansion:167", "sourceNumber": 167, "name": "Mechanism Transfer Test", "body": "Mechanism: Transfer a model across domains by identifying which causal relationships must remain invariant, which variables change and which observations would make the analogy fail. Similar vocabulary or sequence is insufficient.\n\nUse When: Compare railways with AI infrastructure, process platforms with earlier software categories, or a market pattern across countries.\n\nEvidence: Map actors, constraints, feedback, property rights, substitutability and time horizons in both cases; identify at least one consequential mismatch.\n\nFalsifier: The apparent parallel disappears after accounting for a key difference, or the analogy cannot make a prediction beyond what a generic description already gives.\n\nDecision: Transfer only the surviving mechanism and explicitly adapt the strategy to the new environment.\n\nLimits: Historical analogy is a hypothesis generator. Do not inherit dates, returns, monopoly outcomes or geopolitical succession from the reference case.\n\nOrigin: Extension of cross-domain synthesis prompted by the technogeopolitics framework and comparisons with AI.", "sha256": "6346205869b54c38edbd26fd536684f97fb703d6033ff50789cf787209676a41", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0167", "normalizedDefinition": "Transfer a model across domains by identifying which causal relationships must remain invariant, which variables change and which observations would make the analogy fail. Similar vocabulary or sequence is insufficient.", "evidence": "Map actors, constraints, feedback, property rights, substitutability and time horizons in both cases; identify at least one consequential mismatch.", "falsifier": "The apparent parallel disappears after accounting for a key difference, or the analogy cannot make a prediction beyond what a generic description already gives.", "limits": "Historical analogy is a hypothesis generator. Do not inherit dates, returns, monopoly outcomes or geopolitical succession from the reference case." }, { "@id": "urn:business-engineer:source-entry:expansion:168", "@type": "SourceEntry", "id": "expansion:168", "sourceNumber": 168, "name": "Coordination Tax", "body": "Mechanism: When AI makes individual production cheaper, review, integration, decision-making and ownership can become the binding constraints. More generated output may enlarge queues without increasing completed, accepted work.\n\nUse When: Assess AI productivity across engineering, product, GTM and executive work or design an AI-enabled team.\n\nEvidence: Measure end-to-end cycle time, work in progress, rework, reviewer load, decision latency and accepted throughput, not just drafts or tasks generated.\n\nFalsifier: Output growth converts proportionally into accepted throughput without extra coordination cost, or demand rather than coordination is the binding constraint.\n\nDecision: Automate or simplify the handoffs and decisions that constrain completion; reduce unnecessary generation when it only adds queueing.\n\nLimits: Do not assume that fewer people or more Super ICs necessarily improves throughput. Accountability, expertise and coordination still need explicit coverage.\n\nOrigin: Synthesis from AI work across functions, Super IC, deployment bench and productivity discussions, August–September 2026.", "sha256": "2b2dd8edebd926901d4c2174d2674d94eb988bfc6020f29c93cc3efc7fa02a3e", "sourceCategory": "Learning and judgment", "sourceDocument": "urn:business-engineer:source-document:expansion", "canonicalModel": "urn:business-engineer:model:0168", "normalizedDefinition": "When AI makes individual production cheaper, review, integration, decision-making and ownership can become the binding constraints. More generated output may enlarge queues without increasing completed, accepted work.", "evidence": "Measure end-to-end cycle time, work in progress, rework, reviewer load, decision latency and accepted throughput, not just drafts or tasks generated.", "falsifier": "Output growth converts proportionally into accepted throughput without extra coordination cost, or demand rather than coordination is the binding constraint.", "limits": "Do not assume that fewer people or more Super ICs necessarily improves throughput. Accountability, expertise and coordination still need explicit coverage." }, { "@id": "urn:business-engineer:source-entry:pack:137", "@type": "SourceEntry", "id": "pack:137", "sourceNumber": 137, "name": "Node-by-Node Correction", "body": "A technology buildout is a stack of coupled but unsynchronized S-curves. It does not correct as one market; it corrects node by node, in localized drawdowns that are each diagnostic of which position was stretched against which bottleneck. \"Is it a bubble?\" is a malformed question because a bubble presupposes one market. Keep a drawdown ledger: where, when, which species.\n- **Key Q**: \"Which node just repriced, what was it stretched against, and what does that drawdown teach about the map?\"", "sha256": "ac0d83b5148bc551e00c19ff7ea5f38e3a445b11f62af40ea60396d0cd548d56", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0132", "normalizedDefinition": "A buildout can reprice at different nodes and times as local demand, capacity and financing diverge.", "evidence": "Compare node-specific utilization, prices, commitments and funding before and after a drawdown.", "falsifier": "Synchronous deterioration across independent nodes supports a system-wide shock instead.", "limits": "Local and systemic corrections can coexist; a bubble question is not inherently invalid." }, { "@id": "urn:business-engineer:source-entry:pack:138", "@type": "SourceEntry", "id": "pack:138", "sourceNumber": 138, "name": "Two Species of Drawdown", "body": "Localized corrections come in two kinds: supply-constraint repricing (the durability of a physical bottleneck shifts) and financial-absorption repricing (financing outruns what credit will carry). Geopolitics is the shock generator for either. Each node builds its own leverage during its steep segment, which converts a repricing into a crash. Equity violence at a node means duration was repriced, not that the economics broke.\n- **Key Q**: \"Was this a repricing of the bottleneck's durability or of the financing's capacity, and which leverage structure turned it into a crash?\"", "sha256": "bad1e8be036c95c461f2452ac08680c335491067df8d2886da4155d2e4a893ec", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0169", "normalizedDefinition": "Distinguish changes in expected operating cash flows, bottleneck durability, discount rates and financing capacity when explaining a drawdown.", "evidence": "Decompose forecast revisions, interest rates, leverage and liquidity around the event.", "falsifier": "Stable operations with changed discount rates challenges an operating-collapse explanation, and vice versa.", "limits": "Supply and financing are useful lenses, not an exhaustive two-species taxonomy; equity losses can reflect broken economics." }, { "@id": "urn:business-engineer:source-entry:pack:139", "@type": "SourceEntry", "id": "pack:139", "sourceNumber": 139, "name": "The Fifth Clock (Return-Insensitive Demand)", "body": "Beside physical, financial, efficiency, and adoption runs a political clock immune to the return signal: sovereign programs, defense, industrial subsidy, export-control-driven state buildout. Sort past buildouts by outcome and the survivors had a state anchor; the capital-destroyers were purely private. The anchor firms the floor and widens the waste inside it. Do not lower the hurdle for it; split it.\n- **Key Q**: \"How much of this demand never had to clear a return, and does that set a floor or just fund the malinvestment?\"", "sha256": "1678f94afaca675ce9d46084d223ad2a314c63d4af6c956f026b3c85a3a5311f", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0170", "normalizedDefinition": "State objectives can support investment whose sponsor accepts returns different from private investors, changing demand timing and financing resilience.", "evidence": "Identify appropriated budgets, objectives, procurement contracts, cancellation rights and fiscal constraints.", "falsifier": "Cancelled commitments or unchanged investment after state support is removed weaken the proposed demand floor.", "limits": "Political demand is neither unlimited nor return-free and is not necessary or sufficient for a supercycle." }, { "@id": "urn:business-engineer:source-entry:pack:140", "@type": "SourceEntry", "id": "pack:140", "sourceNumber": 140, "name": "The Cascade Is the Rotation", "body": "The bottleneck thesis and techno-geopolitics are one mechanism at two speeds. Whatever binds, earns; whoever solves the bind, rises. Innovation cascades become industrial systems, industrial systems become power systems, power systems become world orders. Read the rotation of the binding constraint as the map of who is gaining power, not only who is earning margin.\n- **Key Q**: \"Who is positioned to relieve the current bind, and what power does that hand them once they do?\"", "sha256": "4a8749f9de8a1d84a4bcbaaed38e9d5b3df9be54829d6fe787e3966566ad9d51", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0138", "normalizedDefinition": "Technologies can shift industrial control and strategic power when complementary production, institutions and permissions convert capability into enforceable advantage.", "evidence": "Trace each conversion step and compare settings with capability but different control.", "falsifier": "Capability without enforceable leverage weakens the claimed conversion.", "limits": "A conceptual cascade is not a universal chronological sequence." }, { "@id": "urn:business-engineer:source-entry:pack:141", "@type": "SourceEntry", "id": "pack:141", "sourceNumber": 141, "name": "Sited, Standardised, Chokeable (The Junction Rule)", "body": "A single technology makes an industry; intersecting technologies make a map. A technology becomes geopolitical when it passes three tests: sited (its physical layer sits somewhere specific), standardised (a gauge or protocol decides who can connect), and chokeable (a small number of points can stop it). Then ask which power form it favours and what it does to war.\n- **Key Q**: \"Is this technology sited, standardised, and chokeable, and at which junction with other technologies does it become a map?\"", "sha256": "b7ea5738b817b323db768bcbfdf07a3f735f75117cddb2e4a27d3573bbca7b8c", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0171", "normalizedDefinition": "Assess whether a technology's production sites, standards and concentrated dependencies expose it to political control.", "evidence": "Map geography, substitutability, standard-setting authority and who can restrict access.", "falsifier": "Accessible substitutes or unenforceable restrictions weaken the claimed junction power.", "limits": "Sited, standardized and chokepoint exposure are separate dimensions; no composite score is supplied." }, { "@id": "urn:business-engineer:source-entry:pack:142", "@type": "SourceEntry", "id": "pack:142", "sourceNumber": 142, "name": "The Independence Swap", "body": "New technology arrives as freedom (from the old constraint) and invoices later as dependency (on the new one). Because the freedom is felt first and the dependency later, the swap is systematically underpriced at adoption. Treat every liberation as a conservation law: the constraint moved; it did not disappear.\n- **Key Q**: \"What dependency is this independence going to invoice, and when does the bill arrive?\"", "sha256": "b80226309501c32621bb1dce65e25e0689af77a2c4e4f6eaf49674a47aca9581", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0172", "normalizedDefinition": "Adopting a technology can reduce one dependency while creating another in inputs, infrastructure, standards or permissions.", "evidence": "Compare dependency and exit maps before and after adoption, including transition costs.", "falsifier": "Independent supply and exercised alternatives can refute a claimed replacement dependency.", "limits": "Independence is multidimensional; replacing a dependency may still be a rational improvement." }, { "@id": "urn:business-engineer:source-entry:pack:143", "@type": "SourceEntry", "id": "pack:143", "sourceNumber": 143, "name": "The Permission Layer", "body": "When the chokepoint is software or standards rather than territory, the border becomes programmable: an export control, a licence, a kill switch, a deemed-export rule. Private assets, public permissions. Map who can revoke, not only who owns.\n- **Key Q**: \"Who holds the permission this system runs on, and what does revocation look like in practice?\"", "sha256": "8890ef37ac069cb274c3266352f223d09e67ab520c2d3887e4cf385e9849ae44", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0173", "normalizedDefinition": "Access to a capability can depend on a party's continuing legal or operational permission even when its physical components are available.", "evidence": "Identify licenses, contracts, credentials, approval authority and revocation conditions.", "falsifier": "An independently operable alternative without the disputed permission weakens the dependency claim.", "limits": "Distinguish legal authority from technical access and verify the applicable rules." }, { "@id": "urn:business-engineer:source-entry:pack:144", "@type": "SourceEntry", "id": "pack:144", "sourceNumber": 144, "name": "The Fence and the Tunnel", "body": "Export fences are tall where the frontier is and thin where trailing-edge tooling suffices. Layers made with trailing-edge equipment are the ones a fence protects least, so the tunnel appears under the fence's shortest section. Read the fence by its thinnest point, not its tallest.\n- **Key Q**: \"Where is this fence thinnest, and which layer is being tunnelled under it?\"", "sha256": "a2d3e9e4cb38292b76f0c81a97e093b29fdb7795492b08592daf3202a89dc7e0", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0174", "normalizedDefinition": "A restriction's economic effect depends on which relevant activities and jurisdictions it actually governs and how enforceably it does so.", "evidence": "Compare the stated control perimeter with lawful supply, substitution and implementation evidence.", "falsifier": "Broad effective coverage and limited substitutes challenge a claim that the restriction is economically porous.", "limits": "This is a policy-effectiveness diagnostic, not an instruction to evade controls." }, { "@id": "urn:business-engineer:source-entry:pack:145", "@type": "SourceEntry", "id": "pack:145", "sourceNumber": 145, "name": "State Capital Does Not Under-Build", "body": "A toll rests on all capable producers under-building. When a state entrant's objective is share and sovereignty rather than return, the discipline is no longer universal. The historical rhyme: the incumbent that took the layer as a state-championed latecomer decades ago is now watching the same play aimed back at it. Near term the fence holds on physics; medium term the challenger attacks both pillars.\n- **Key Q**: \"Is every producer in this layer still disciplined by ROIC, or has a state actor changed the objective function?\"", "sha256": "57a46535e0db6c9f10e77ca6522470a048312526dd296dae1531a5e5dc4977cf", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0175", "normalizedDefinition": "Capacity funded for strategic objectives can alter prices and investment incentives even when its sponsor uses a different return threshold.", "evidence": "Track funded capacity, delivery, utilization and price changes against a counterfactual supply path.", "falsifier": "Undelivered or uneconomic-to-operate capacity that does not change supply weakens the effect.", "limits": "Announced investment is not delivered supply; demand growth and product differences matter." }, { "@id": "urn:business-engineer:source-entry:pack:146", "@type": "SourceEntry", "id": "pack:146", "sourceNumber": 146, "name": "The Toll-Booth State", "body": "A national economy can be functionally one layer of the stack: it collects that layer's rent in full and absorbs its shocks in full, with household leverage stacked on the national position. Its index is a real-time price of the layer. Read it as an instrument, and read its energy dependence as the short beneath the long.\n- **Key Q**: \"Which country is this layer, and what is stacked on top of that position?\"", "sha256": "18c59647866eb1c9ec8f07ed84e10104764e145d3539b03c4a21d487abcb94c5", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0176", "normalizedDefinition": "A sector's contribution to national income, exports or assets can create concentrated economic and political exposure.", "evidence": "Use consistent value-added, export, employment and fiscal measures, with supplier dependencies separated.", "falsifier": "Diversified domestic value creation and low exposure under a sector shock weaken the concentration thesis.", "limits": "Company revenue is not interchangeable with GDP or national income." }, { "@id": "urn:business-engineer:source-entry:pack:147", "@type": "SourceEntry", "id": "pack:147", "sourceNumber": 147, "name": "Market Risk Becomes Counterparty Risk (The Wire)", "body": "Take-or-pay contracts with floors delete spot-price risk and replace it with buyer-credit risk. If the buyers are the debt-financed builders, the physical floor is contractually wired to the ceiling's credit. The wire is what gets priced when the ceiling wobbles. Deposits are demand collateralizing its own persistence.\n- **Key Q**: \"When this floor contracted away its price risk, whose credit did it accept instead?\"", "sha256": "9fb925360f7a91be935d172c2612ec9699ec9579f3eb3be8f80f10f377cb8ef7", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0177", "normalizedDefinition": "A price floor or purchase commitment can replace some market-price exposure with counterparty and contractual exposure.", "evidence": "Read price, volume, indexation, termination, collateral and guarantee provisions alongside counterparty capacity.", "falsifier": "Uncovered volume or unenforceable support challenges the claimed protection.", "limits": "Basis, timing, performance, demand and enforcement risks may remain." }, { "@id": "urn:business-engineer:source-entry:pack:148", "@type": "SourceEntry", "id": "pack:148", "sourceNumber": 148, "name": "Shape Cannot Be Contracted", "body": "A long-term agreement buys certainty of payment, not certainty of shape. Demand can keep its size and change where it concentrates across the map; committed supply cannot follow. Look for the clause that leaves new-product pricing \"to be negotiated\": that is the shape risk the contract could not remove.\n- **Key Q**: \"What does this contract fix, and what does it leave to move?\"", "sha256": "16d7f1c217fab9e1a3d9ed54bd9e0f2d1ca70f276770e35ad79ca5599ef248e1", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0178", "normalizedDefinition": "Predictable contracted payments and the ability to adapt an asset to changing demand are separate sources of resilience.", "evidence": "Stress payment obligations and asset reuse under technology and customer changes.", "falsifier": "Secure payment with stranded capacity, or flexible capacity without funding, breaks the inference that one ensures the other.", "limits": "Do not treat payment certainty as proof of asset usefulness or solvency." }, { "@id": "urn:business-engineer:source-entry:pack:149", "@type": "SourceEntry", "id": "pack:149", "sourceNumber": 149, "name": "The Transmission Belt", "body": "A buildout's cost escapes the complex through shared inputs into consumer prices: a company that builds nothing raises prices because of the build, a central bank names the buildout in the same breath as war and tariffs, the curve steepens, and the build's own debt costs more. Capex as an inflation source is a loop, not a line.\n- **Key Q**: \"Through which shared input does this buildout reach a price a household pays, and how does that price come back as a cost of capital?\"", "sha256": "30f4b0b57b682078bba5fbc1b2c0046d9757e6299f9e54ebe315751c96271f23", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0179", "normalizedDefinition": "Input or energy cost shocks can affect prices, interest rates, financing capacity and subsequent investment through several contingent channels.", "evidence": "Trace pass-through, policy response, real rates and funding conditions with dated evidence.", "falsifier": "Absorbed costs or offsetting monetary and demand effects weaken the proposed transmission.", "limits": "The sign and strength depend on contracts, policy and the broader economy." }, { "@id": "urn:business-engineer:source-entry:pack:150", "@type": "SourceEntry", "id": "pack:150", "sourceNumber": 150, "name": "Same Tide, Different Beaches", "body": "One efficiency event lands differently on different shores. Cheaper, open models raise total serving demand while redistributing it from concentrated blocks (frontier training) to a broader hierarchy (distributed serving, context stores). Ask which shore each supplier stands on before calling the tide bullish or bearish.\n- **Key Q**: \"Which shore does this company stand on when the tide comes in, and is the tide redistributing demand or removing it?\"", "sha256": "4addcf89cef3f845d77754a14b17aca6d63e57cc4b5a1e85fd226f9751d316b3", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0134", "normalizedDefinition": "Efficiency gains are divided among users, suppliers and intermediaries according to competition, contracts and elasticity.", "evidence": "Measure cost decline, price pass-through, volume and margins across the affected layers.", "falsifier": "Falling unit costs without downstream price or volume change weakens a claimed demand expansion.", "limits": "Total spending can rise or fall; aggregate benefit does not protect every asset vintage." }, { "@id": "urn:business-engineer:source-entry:pack:151", "@type": "SourceEntry", "id": "pack:151", "sourceNumber": 151, "name": "Demand Subtraction Wearing a Supply Costume", "body": "A challenger's vertical integration adds wafers and removes buyers at the same time. Watch the challenger's revenue share inside the incumbents' books: repatriated procurement is demand subtraction, even when it is reported as new supply.\n- **Key Q**: \"Is this new capacity adding to the market or removing a customer from it?\"", "sha256": "09f464c134c25f7c84c26df2f6c0528580c9c124354d5646339e313ace7d375b", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0180", "normalizedDefinition": "Vertical integration can reduce purchases in an open merchant market while the underlying service or workload continues growing internally.", "evidence": "Reconcile third-party sales, internal capacity and total workload with consistent boundaries.", "falsifier": "Stable merchant share alongside integration weakens the claimed compression.", "limits": "Captive and merchant capacity are not automatically equivalent in cost or performance." }, { "@id": "urn:business-engineer:source-entry:pack:152", "@type": "SourceEntry", "id": "pack:152", "sourceNumber": 152, "name": "The Land–Sea Oscillation and the Blockade's Medium", "body": "Junction technologies decide whether power favours the maritime or the continental form, and each junction changes the medium a blockade runs through: sea lanes, then rail, then fuel, then chips, then compute. Mass returns when a cheap, producible unit can be made faster than an exquisite platform can be defended.\n- **Key Q**: \"Through which medium would a blockade of this system run, and does the current junction favour mass or exquisiteness?\"", "sha256": "be95c674cfe13a2c375a3427f844b0f879660c8c7103e74630085c2072701292", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0181", "normalizedDefinition": "The geography and substitutability of production can change how disruption affects economic and strategic power.", "evidence": "Compare historically documented production capacity, replacement time and supply continuity.", "falsifier": "Rapid substitution or dispersed production weakens a concentration-based exposure claim.", "limits": "Historical strategic analysis requires case-specific evidence; no operational targeting guidance is implied." }, { "@id": "urn:business-engineer:source-entry:pack:153", "@type": "SourceEntry", "id": "pack:153", "sourceNumber": 153, "name": "The Three-Generation Lag and the Domestic Bill", "body": "A junction's power effects arrive roughly three generations after the technology, and the distributional politics arrive first at home: rate-payers, regional losers, and the commissions that get created to settle them. Any forecast that skips the domestic bill skips the politics that decide the timing.\n- **Key Q**: \"Who pays the domestic bill for this buildout, and what institution will be created to settle it?\"", "sha256": "bff7fc3ce341e4724a245ed9f29c8d7f662611b0c7e1d2167ab0c088cbb4be07", "sourceCategory": "XVII. THE SUPERCYCLE PREMISE, THE FIFTH CLOCK, AND THE GEOPOLITICAL LAYER (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0141", "normalizedDefinition": "New industrial capabilities may take time to alter institutions, strategic power and domestic economic burdens.", "evidence": "Date capability, adoption, institutional response and distributional effects separately.", "falsifier": "Concurrent change or reversed sequencing challenges a proposed lag mechanism.", "limits": "No fixed three-generation interval is supported by the source." }, { "@id": "urn:business-engineer:source-entry:pack:154", "@type": "SourceEntry", "id": "pack:154", "sourceNumber": 154, "name": "Name the Seat First", "body": "A print is misread when its seat is wrong. Ten seats: builder · bystander (downstream input incidence) · distributor (discovery incidence) · control group (expensed, opted out) · supplier (paid by the build) · funder (supplies the build's capital) · integrator (floats the build's working capital) · value-capture pole (paid by the build, finances no floor) · rail (settlement the build cannot disintermediate) · taxed (attention the build summarizes). Each seat has its own tests; run the seat's tests, not the builder's.\n- **Key Q**: \"Which of the ten seats is this company in, and am I running that seat's test or someone else's?\"", "sha256": "0d54956c56320a68fb5b4d81682fde407743101db1903d0d2e8ab58c805c53b8", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0182", "normalizedDefinition": "Classify an actor's position in a flow of spending, production, financing, access and incidence before applying a performance test.", "evidence": "Name the payer, contractual role, unit, layer and horizon for each exposure.", "falsifier": "Different conclusions for different exposures within one company show that a single firm-wide seat is insufficient.", "limits": "The ten seats overlap; a renter is a comparator, not automatically a causal control group." }, { "@id": "urn:business-engineer:source-entry:pack:155", "@type": "SourceEntry", "id": "pack:155", "sourceNumber": 155, "name": "The Value-Capture Pole (The Anti-Capex Node)", "body": "The node that gets paid BY the build while financing none of the floor: capex near zero, off both physical and financial clocks, priced on outcomes rather than consumption. It is the ceiling made legible. Its whole risk collapses onto the multiple, because there is no long-lived asset to look through to.\n- **Key Q**: \"Does this company pay for the build or get paid by it, and if the latter, where does its risk live?\"", "sha256": "f4201d500694918fd9cee736126fbbd003418c3a376187e088fb7804768e56a5", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0183", "normalizedDefinition": "Low owned capital can coexist with substantial lease, minimum-purchase, supplier, access and counterparty obligations.", "evidence": "Reconcile owned assets with leases, contracted capacity and economically necessary purchases.", "falsifier": "Flexible cancellable access with adequate alternatives weakens a claimed hidden capital burden.", "limits": "Asset-light is a balance-sheet and operating description, not a synonym for low risk." }, { "@id": "urn:business-engineer:source-entry:pack:156", "@type": "SourceEntry", "id": "pack:156", "sourceNumber": 156, "name": "Proof of Concept, Not Reconciliation", "body": "One node monetizing the ceiling at high margin proves the return exists; it does not scale to the capital. Hold both: the highest-quality single instance of return-side monetization and its size against the build. Refuse to let either clause delete the other.\n- **Key Q**: \"Is this return real, and is it remotely scaled to the capital it is supposed to justify?\"", "sha256": "722ea1e558d9939445f55d957b67ac64ae028a06d5880ec57ef81e460f2a6418", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0184", "normalizedDefinition": "A viable product or profitable node does not establish that the surrounding industry's investment can earn adequate returns.", "evidence": "Compare local unit economics with aggregate capital, final demand and duplication across layers.", "falsifier": "A consistent system-level cash-flow reconciliation can support broader viability beyond the local proof.", "limits": "Do not sum intermediate supplier revenue as independent final demand." }, { "@id": "urn:business-engineer:source-entry:pack:157", "@type": "SourceEntry", "id": "pack:157", "sourceNumber": 157, "name": "Price Is the Whole Position", "body": "Where there is no multi-year asset, the long-duration instrument is the terminal margin or the multiple, nothing else. A business can accelerate while its stock de-rates, because the discount rate moved and the business did not. Separate the two before writing a verdict.\n- **Key Q**: \"If this company has no asset to reprice, what is the tape actually repricing?\"", "sha256": "67e283e5a89f0378e23b402e704a575031b79edb80a40c8185992e428f4210fa", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0185", "normalizedDefinition": "An operating business can improve while its valuation falls because expectations, discount rates or the timing of cash flows change.", "evidence": "Reconcile operating revisions, priced growth, discount rates and cash-flow duration.", "falsifier": "Deteriorating expected operations challenges a pure-duration explanation.", "limits": "A price decline is evidence to explain, not proof of unchanged economics." }, { "@id": "urn:business-engineer:source-entry:pack:158", "@type": "SourceEntry", "id": "pack:158", "sourceNumber": 158, "name": "The Beat Raises the Hurdle", "body": "When a supplier's shipments accelerate, the end-customer revenue required to earn a return on those shipments rises with them. A record at the supply layer is evidence against the monetization case, not for it, until the demand side compounds at the required rate.\n- **Key Q**: \"How much new end-customer revenue does this beat now require, and is it appearing?\"", "sha256": "6f0e125c283591c94ec7086fbe61ff87fe4528d26674c64ff54bfdfae1494abd", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0112", "normalizedDefinition": "An increase in supplier shipments can increase the asset vintages and commitments that customers must monetize; update the return hurdle using actual capital exposure and the expected demand path.", "evidence": "Trace shipments into installed capacity, timing, customer obligations and incremental final-demand cash flows; distinguish replacements and inventory from additional productive capital.", "falsifier": "Replacement shipments, falling total capital cost or independently rising profitable utilization can overturn an inferred increase in the monetization gap.", "limits": "A supplier beat is not automatically evidence against monetization. Reconcile capital and revenue boundaries; capex at three times depreciation alone implies no fixed revenue growth rate." }, { "@id": "urn:business-engineer:source-entry:pack:159", "@type": "SourceEntry", "id": "pack:159", "sourceNumber": 159, "name": "Stretch From Strength", "body": "A company can trigger every collapse condition (capex above operating cash flow, a return to the bond market) from operating strength. That is a placement decision, not distress, and it is still stretch. Grade the engine and the financing separately.\n- **Key Q**: \"Did the financing change because the engine weakened or because it chose to build faster than cash allowed?\"", "sha256": "aa09a8c6b2a26208d6766fca04346f8503dbbc4ff026628179646536653d4c20", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0115", "normalizedDefinition": "A company can cover operating charges while stretching its ability to fund investment, maturities and working capital.", "evidence": "Reconcile operating earnings, cash generation, capex, commitments and liquidity over matching periods.", "falsifier": "Adequate stressed funding coverage weakens a claim of cash strain despite heavy investment.", "limits": "Operating strength and funding resilience are separate tests." }, { "@id": "urn:business-engineer:source-entry:pack:160", "@type": "SourceEntry", "id": "pack:160", "sourceNumber": 160, "name": "The Related-Party Triple (The Circle)", "body": "One counterparty relationship can generate an investment, a capacity commitment, and a revaluation mark at once. Supplier equity, supplier credit, and supplier guarantees flow out as customer revenue flows in. A valuation that counts the revenue and the mark values the same dollar twice. Trace the circle before reading either.\n- **Key Q**: \"How many effects does this one relationship produce in the accounts, and which of them are the same dollar?\"", "sha256": "8372cdc0f6bff3e1fdb06b32d4368492c898c2a85099e6a751ec1f807c42fcf3", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0186", "normalizedDefinition": "A supplier, investor and customer relationship can create correlated funding and revenue exposure when money moves through linked counterparties.", "evidence": "Trace counterparties, funding sources, commercial contracts, timing and related-party disclosures.", "falsifier": "Independent customer budgets and sustained purchases without supplier financing weaken a circular-dependence thesis.", "limits": "Such revenue is not automatically fictitious; accounting recognition and demand independence are different questions." }, { "@id": "urn:business-engineer:source-entry:pack:161", "@type": "SourceEntry", "id": "pack:161", "sourceNumber": 161, "name": "The Levered Backer", "body": "When a holding company funds a build's first-loss equity by borrowing against its own marked-to-market stakes, the equity is debt, the collateral is marks, and the marks are the thing being bought. A fair-value trigger writes a margin call into the equity layer. The cushion everyone assumed absorbs the shock is wired to transmit it.\n- **Key Q**: \"Is the first-loss equity beneath this structure real equity, or borrowed against the asset it bought?\"", "sha256": "5bbb77c74ec76e6d9106ee2c4718698a9e09ecbf769e7d42d03e2ebc94147524", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0187", "normalizedDefinition": "Borrowing to fund equity exposure combines a relatively fixed obligation with a volatile residual claim.", "evidence": "Stress debt service, collateral, refinancing and equity value under correlated shocks.", "falsifier": "Unlevered exposure or matching long-term committed resources weakens a forced-sale thesis.", "limits": "Funding maturity, recourse and liquidity determine the risk, not equity ownership alone." }, { "@id": "urn:business-engineer:source-entry:pack:162", "@type": "SourceEntry", "id": "pack:162", "sourceNumber": 162, "name": "The Frozen Mark", "body": "A private stake carried at an unchanged valuation while every other input moves is a choice, not a measurement. The frozen mark postpones the read; it does not remove it. Note where the mark stands relative to the last transaction and what event forces it to move.\n- **Key Q**: \"Which mark in this book has not moved, and what would force it to?\"", "sha256": "63b72c2357f1d43d3f3891af13b9a42596a029ecdafaeb717762ee867407fe9e", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0188", "normalizedDefinition": "Reported marks for illiquid holdings can adjust later or less frequently than observable market conditions.", "evidence": "Compare valuation dates, methodologies, transactions and subsequent events for comparable exposures.", "falsifier": "Independent contemporaneous transactions supporting a mark weaken a lag claim.", "limits": "An unchanged mark alone is not evidence of manipulation or an incorrect valuation." }, { "@id": "urn:business-engineer:source-entry:pack:163", "@type": "SourceEntry", "id": "pack:163", "sourceNumber": 163, "name": "Backlog as Payable (The Customer Is the Lender)", "body": "Two operators can run the same build with opposite balance-sheet signs: one carries backlog as a receivable financed by debt, the other carries prepayments as deferred revenue and holds net cash. Strip the prepayments from operating cash flow before reading the engine. The pre-funded operator's risk is depreciation and concentration, not financing.\n- **Key Q**: \"Is this backlog a receivable I financed or a payable my customer prefunded, and which risk does that leave me holding?\"", "sha256": "69d534a3f689d161e5a018f135931e5d24338380e28ac1e5e46248c42347e91e", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0189", "normalizedDefinition": "Customer cash collected before delivery can fund operations while creating delivery, refund and concentration obligations.", "evidence": "Reconcile billings, cash receipts, receivables, contract assets, contract liabilities and delivery schedules.", "falsifier": "Short-lived advances offset by refunds or supplier payments weaken a durable-float thesis.", "limits": "Backlog is not automatically a receivable or liability; classify rights and performance obligations separately." }, { "@id": "urn:business-engineer:source-entry:pack:164", "@type": "SourceEntry", "id": "pack:164", "sourceNumber": 164, "name": "Assembly Is Not Capture (The Integrator Floats the Timing Gap)", "body": "The assembly point converts capital into racks at low margin, negative cash conversion, and rising trade credit extended to weaker tenants. The integrator carries the build's working capital on its own book, funded by dilution and debt. Trade-credit float is a financing channel the six gauges cannot see; inventory is the fastest collateral to reprice.\n- **Key Q**: \"Who is carrying the working capital of this build, and is it being extended as trade credit to counterparties the acid test never scores?\"", "sha256": "34e717df821aa2eb08b7c73cd3aa6328c3ee08daac94665da7435e3b90f3ccbf", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0190", "normalizedDefinition": "An integrator can finance the gap between supplier payment and customer collection even when it owns little long-lived infrastructure.", "evidence": "Measure inventory, payment terms, receivable aging, credit insurance and stressed cash conversion.", "falsifier": "Matched payment timing or reliable nonrecourse transfer weakens the financing-gap thesis.", "limits": "The original financing gauges need a trade-credit supplement to capture this exposure." }, { "@id": "urn:business-engineer:source-entry:pack:165", "@type": "SourceEntry", "id": "pack:165", "sourceNumber": 165, "name": "Tightness Rent vs Monopoly Rent (The Arms Dealer)", "body": "A supplier's margin can expand with the build because the input is tight, not because the position is a monopoly. Tightness rent is cyclical and competed; monopoly rent is structural. Separate them, and note when the anchor customer is also the biggest competitor.\n- **Key Q**: \"Is this margin a property of the constraint or of the position, and who else can supply once the constraint eases?\"", "sha256": "5006e447f0ddd0920b11669890d5a4b33c82594ce982434391f77bb77803c68e", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0191", "normalizedDefinition": "Separate returns caused by a temporary shortage from returns sustained by hard-to-replicate control, capabilities or relationships.", "evidence": "Track capacity additions, substitutes, price premiums, retention and bargaining power after scarcity eases.", "falsifier": "Persistent premiums with verified customer value challenge a purely temporary-rent diagnosis.", "limits": "The two mechanisms can coexist; high margins alone identify neither." }, { "@id": "urn:business-engineer:source-entry:pack:166", "@type": "SourceEntry", "id": "pack:166", "sourceNumber": 166, "name": "Incidence Runs Opposite at the Two Ends", "body": "The same build costs the application layer (inference in cost of goods) and pays the physical supply layer (margin expanding with tightness). The middle pays both. Never read one end's incidence as the sign for the whole stack.\n- **Key Q**: \"At which end of the stack is this company, and does the build cost it or pay it?\"", "sha256": "bbfe672722f3ec7dce479f1a88534190c81cf100ec52ddb9faf2662e5c969abb", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0127", "normalizedDefinition": "The party initially receiving or paying cash may pass costs or benefits to other layers through contracts and prices.", "evidence": "Follow contractual adjustments and pass-through in both directions, with elasticities where estimable.", "falsifier": "Fixed terms or strong alternatives can block the predicted transmission.", "limits": "Incidence does not have a universal direction." }, { "@id": "urn:business-engineer:source-entry:pack:167", "@type": "SourceEntry", "id": "pack:167", "sourceNumber": 167, "name": "The Vertical Wrapper (Paying to Enter the Build)", "body": "A designer that also operates the cloud and finances its own demand on one balance sheet can report core revenue that is partly a warrant add-back: equity given to customers, amortized as contra-revenue, then added back. Customers prepay and are paid in equity at once. The razor comes with equity.\n- **Key Q**: \"How much of this 'core' revenue is an add-back of equity handed to the customer?\"", "sha256": "2036d875c27840e4bd0fce75002dafb7fcf249c2d317cda1f1e3c1585c7e0364", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0192", "normalizedDefinition": "Equity or warrant incentives offered to customers can alter effective pricing, acquisition economics and the distribution of business risk.", "evidence": "Value contractual incentives consistently and compare retention and purchases after subsidies expire.", "falsifier": "Unsubsidized repeat demand weakens a thesis that the incentive alone supports the relationship.", "limits": "Noncash incentives still have an economic cost; avoid double counting dilution and expense adjustments." }, { "@id": "urn:business-engineer:source-entry:pack:168", "@type": "SourceEntry", "id": "pack:168", "sourceNumber": 168, "name": "The Sibling Engine (The Gravity Shift)", "body": "When a founder's second company out-earns the first and the first's reported profit is mostly a mark on the second, gravity has shifted inside the group. Read the profit source, the talent currency, and the capital priority as one system, and read the compute they share as the flywheel for both.\n- **Key Q**: \"Which entity in this group is now the engine, and which is being carried by a mark on it?\"", "sha256": "562f87e2024ba24180ef5d102fae24cca81d309f780803eeab0e3eea2f2c5143", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0193", "normalizedDefinition": "A diversified group's source of value can shift between businesses even while aggregate results conceal the transition.", "evidence": "Bridge segment cash flows, capital requirements and risk to group valuation over time.", "falsifier": "Stable segment contributions weaken a proposed migration of the value center.", "limits": "Intersegment transactions and shared costs need reconciliation." }, { "@id": "urn:business-engineer:source-entry:pack:169", "@type": "SourceEntry", "id": "pack:169", "sourceNumber": 169, "name": "Capex Is a Placement Decision (The Six Tiers)", "body": "Capex only ever measured the part of a build a company chose to own. Obligations descend a ladder of visibility: capitalized · recorded as lease · signed-not-commenced · non-cancelable commitments · contingent guarantees · non-consolidated vehicle debt · someone else's capex. The footnote compounds faster than the capex line, and position on the ladder reveals rating headroom. Growth financed by moving down the ladder is the Descent; the ladder has a bottom where investment grade ends.\n- **Key Q**: \"On which rung of the ladder is the marginal dollar of this build being placed, and what does that rung confess about headroom?\"", "sha256": "03e71a7dec9e763e03a0b8b2a587a72ad2289c6d07db1a951a367585cb2abf92", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0120", "normalizedDefinition": "Assess which financing source funds the next commitment and how visible its terms and retained exposure are.", "evidence": "List the seven financing categories named in the source and document terms, recourse and disclosure gaps.", "falsifier": "A transparent marginal financing path can refute a claimed opaque funding dependence.", "limits": "The source says six tiers but lists seven; this is a visibility checklist, not a universal rank." }, { "@id": "urn:business-engineer:source-entry:pack:170", "@type": "SourceEntry", "id": "pack:170", "sourceNumber": 170, "name": "The Rating Is the Collateral", "body": "An isolation vehicle is a way to pledge a credit rating, not a way to finance a datacentre: the tenant's rating caps the vehicle's, the guarantee that keeps it off the books leaks through five seams, and a four-tenor mismatch (mini-perm, securitisation, hardware life, contract, institutional appetite) is bridged by a take-out assumption. The certainty gap (tenants need capacity certainty before signing; lenders need signed contracts before funding) is why private credit owns the cycle.\n- **Key Q**: \"Which rating is really being pledged here, through which seam would it leak, and who is assumed to take the paper out?\"", "sha256": "3eab168d5b606919bdf90cad8f0f61d4f952c150a777830d73a87a1633d7700a", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0194", "normalizedDefinition": "Long-lived asset financing often depends on the credit quality and tenor of customers, sponsors or other contractual supporters.", "evidence": "Match asset life and five listed tenor categories with funding maturities, support and refinancing conditions.", "falsifier": "Weak or short-lived credit support can break financing even when the asset has demand.", "limits": "The source says four tenors but lists five; support reduces some risks without eliminating them." }, { "@id": "urn:business-engineer:source-entry:pack:171", "@type": "SourceEntry", "id": "pack:171", "sourceNumber": 171, "name": "Efficiency Is Obsolescence From the Collateral Side", "body": "Cheaper compute is good for the category and lethal to a vehicle collateralized on a specific facility, hardware generation, tenant, and term. The efficiency clock absorbs physical-clock damage and accelerates financial-clock damage. Sector good news is structure bad news.\n- **Key Q**: \"Which specific collateral does this efficiency gain reprice, and who is holding paper against it?\"", "sha256": "337d614716bba66657e4af53453b168c7429f4cfefc9df2c3c10bea176f9d9f6", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0134", "normalizedDefinition": "Efficiency can reduce older assets' earning power and collateral value, transmitting through leverage, covenants and refinancing to the vehicle's creditors.", "evidence": "Compare vintage utilization and residual values with tenant contracts, loan-to-value terms, covenants, maturities, guarantees and recourse.", "falsifier": "Durable contracted cash flows, low leverage or adequate replacement collateral can block the predicted credit transmission.", "limits": "Efficiency benefits do not guarantee impairment or creditor loss; the contract and funding structure determine who bears repricing." }, { "@id": "urn:business-engineer:source-entry:pack:172", "@type": "SourceEntry", "id": "pack:172", "sourceNumber": 172, "name": "The Rack Ate a Layer (The Invisible Channels)", "body": "When the unit of sale moves from chip to rack, the fabric inside the rack disappears from merchant networking revenue. Internal silicon reroutes the accelerator dollar to foundry, packaging, and memory without appearing in any third-party line. Captive fabric appears in nobody's numbers. Merchant reads understate the build.\n- **Key Q**: \"Which channels of this build are invisible to the public numbers, and how much does that bias the read?\"", "sha256": "ef5fa4fb92f3b711d00978319fb5a5006f96a4b86cad4adce2288648ebb2fc13", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0195", "normalizedDefinition": "Separate open-market transactions from internal production when estimating market size, shares and investment returns.", "evidence": "Reconcile merchant revenue, captive capacity, internal transfers and final-customer spending.", "falsifier": "A stable reconciled boundary can overturn a growth claim driven only by reclassification.", "limits": "Use different totals for different questions and never silently add them." }, { "@id": "urn:business-engineer:source-entry:pack:173", "@type": "SourceEntry", "id": "pack:173", "sourceNumber": 173, "name": "Collection Becomes Cash (The Second Climb)", "body": "The inverse of allocation becoming obligation: a toll collector converts rent to net cash, de-levers, and starts a second climb into an adjacent layer on the strength of its base. Read the second climb as the toll's reinvestment, and read its dilution against per-share leverage.\n- **Key Q**: \"Where is this toll collector reinvesting its rent, and does the second climb compound the first or dilute it?\"", "sha256": "2925c73bc748508501588b48f485319b79f3785ce3915586046a04efcf81d72b", "sourceCategory": "XVIII. NODE READS — THE TEN SEATS ON THE FINANCIAL CLOCK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0040", "normalizedDefinition": "A scarce or defended position can generate cash that funds expansion, debt reduction or shareholder returns; test whether reinvestment creates a reinforcing advantage.", "evidence": "Trace operating cash conversion, capex, net debt, dilution and per-share outcomes alongside the new capability's retention and bargaining effects.", "falsifier": "Persistent subsidy, poor cash conversion or dilution without incremental advantage weakens the compound-moat thesis.", "limits": "Cash accumulation, deleveraging and a new moat are distinct outcomes; adjacency and available cash alone do not establish reinforcement." }, { "@id": "urn:business-engineer:source-entry:pack:174", "@type": "SourceEntry", "id": "pack:174", "sourceNumber": 174, "name": "Software Acquires a Cost of Goods", "body": "Inference makes zero marginal cost false. A build reaches the pure software layer through the income statement in real time: gross margin compresses as inference lands in cost of goods, operating margin compresses as the feature race lands in opex. This is the fifth incidence path and it finishes at the top of the stack. A first-party model is the cost-of-goods lever that turns it.\n- **Key Q**: \"Where in this software P&L is the inference bill landing, and what lever pulls the margin back?\"", "sha256": "2549d789ca3b4bf4417d8d387142eaffa133c5fb3da622ee10733ebfdde3a471", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0196", "normalizedDefinition": "AI can add workload-sensitive production costs to software and redistribute margin pressure through the product and supplier stack.", "evidence": "Measure inference, tools, support, retries and review cost by user and accepted outcome.", "falsifier": "Low or declining incremental cost relative to realized value weakens a margin-compression thesis.", "limits": "Software already had nonzero costs; AI cost structure varies by architecture and usage." }, { "@id": "urn:business-engineer:source-entry:pack:175", "@type": "SourceEntry", "id": "pack:175", "sourceNumber": 175, "name": "The Discovery Tax (The Curse Is in the Funnel)", "body": "The force that makes human data scarce and valuable also disintermediates the free top of the funnel that acquired the audience. Revenue is the trailing monetization of a channel now closing. Read the leading indicator (traffic, logged-in users, referral commentary), not the lagging one (revenue), and note that the two revenue lines can carry opposite exposures to the same force.\n- **Key Q**: \"Is this revenue being generated by the funnel or by squeezing a base the funnel stopped refilling?\"", "sha256": "7ee3961617435ad1400a630dc03129a3782fe4ab27a23d9a0c6ae2682df71fb1", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0197", "normalizedDefinition": "A change in how users discover answers can reduce or redirect referrals and monetization for businesses dependent on the prior channel.", "evidence": "Track task-level impressions, referrals, conversion, direct demand and alternate acquisition routes.", "falsifier": "Stable profitable conversion despite fewer visits weakens a revenue-loss inference.", "limits": "Traffic, qualified demand and revenue are distinct; effects differ by task and segment." }, { "@id": "urn:business-engineer:source-entry:pack:176", "@type": "SourceEntry", "id": "pack:176", "sourceNumber": 176, "name": "Content Is Summarizable, Settlement Must Clear", "body": "The agentic force disintermediates the attention web and cannot disintermediate the settlement web. An answer replaces a visit; a transaction still has to clear. Same force, opposite sign, and the sign is set by whether the asset is content or a rail.\n- **Key Q**: \"Can an agent satisfy this demand with a summary, or does something still have to clear?\"", "sha256": "1e7118b26dd5bc8faef1a3fff32e82495c93785562502759489b8bc76d6c76fb", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0198", "normalizedDefinition": "An agent may substitute for an informational step without being able or authorized to complete the associated transaction.", "evidence": "Test discovery, interpretation, permission, payment and exception handling separately.", "falsifier": "Successful authorized completion can refute a claim that the business controls an indispensable final step.", "limits": "A content response is not evidence of execution capability." }, { "@id": "urn:business-engineer:source-entry:pack:177", "@type": "SourceEntry", "id": "pack:177", "sourceNumber": 177, "name": "Rent the Agent, Own the Rail (AGaaS)", "body": "The routing-fabric doctrine ported to commerce and applications: agents are the interchangeable field; the catalog, the checkout, the protocol, and the capture are the owned junction. The same move at three sites: the settlement rail, the creation substrate, the semantic layer. Structured data is a preference moat when agents pick the machine-readable listing.\n- **Key Q**: \"Which agent-facing junction does this company own, and is it structured well enough that agents prefer it?\"", "sha256": "08742bbf072322a65555cd2149a4ac475225fe01c072637366f926362e66f33d", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0135", "normalizedDefinition": "Decide which transaction authority, customer relationship and operational knowledge should remain under a business's control as interfaces change.", "evidence": "Map ownership, permission and exit at discovery, selection, purchase and post-purchase stages.", "falsifier": "Transferable customers and reliable alternative execution weaken a claimed captured junction.", "limits": "Control can be contractual; owning every layer is not required." }, { "@id": "urn:business-engineer:source-entry:pack:178", "@type": "SourceEntry", "id": "pack:178", "sourceNumber": 178, "name": "The Toll Authority (The Property Line Repriced)", "body": "The attempt to move content across the summarizable line: a payment gate between agent and page converts the discovery tax into metered revenue, paid in traffic today and in stablecoins tomorrow. The position can be secured before the till exists, and the gross margin carries the machine web free until the toll collects. Watch the gross-margin turn as the gauge.\n- **Key Q**: \"Has this toll authority secured the position, and is it collecting yet or still carrying the traffic free?\"", "sha256": "0e2b34074d43c880375b817072e66c6402fcce2323abb9211da78fd3d14a62b4", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0199", "normalizedDefinition": "A business may charge for reliable machine access to information, actions or outcomes when those services create measurable value.", "evidence": "Test paying demand, access rights, substitution, service quality and delivery cost.", "falsifier": "Cheap equivalent lawful access or weak willingness to pay undermines the toll thesis.", "limits": "Technical access control alone does not create a durable rent." }, { "@id": "urn:business-engineer:source-entry:pack:179", "@type": "SourceEntry", "id": "pack:179", "sourceNumber": 179, "name": "The Interface Concession", "body": "When human app usage is flat while agent calls through an open protocol compound, an incumbent priced per seat faces a choice: defend a front door nobody opens or become the governed substrate under every agent. Conceding the interface is the correct call and a downgrade at once, because metered access to the customer's own record is smaller and more contestable than a seat.\n- **Key Q**: \"Has this incumbent conceded the interface, and what is the substrate business worth once it has?\"", "sha256": "eb60da62193885a2be7a2e134105d065b17bd999fce0c4cf72627017d711609f", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0200", "normalizedDefinition": "A product can lose control of the user interface yet retain value as the system that performs transactions, enforces rules or stores authoritative state.", "evidence": "Separate interface usage from backend transaction volume, switching cost and retained economics.", "falsifier": "Replaceable backend services with falling retained margin weaken the substrate defense.", "limits": "Losing the interface may still weaken distribution and bargaining power." }, { "@id": "urn:business-engineer:source-entry:pack:180", "@type": "SourceEntry", "id": "pack:180", "sourceNumber": 180, "name": "Substitution Shows Up in the Segments Before the Total", "body": "A growing total can hide product lines going negative. Agents calling systems directly route around integration middleware first; a model that queries and narrates replaces the dashboard second. Read the retiring segment appendix before it disappears, and read the adoption chart and the segment chart as one fact seen twice.\n- **Key Q**: \"Which segment inside this total has gone negative, and which agent behaviour explains it?\"", "sha256": "fd9af4a67d01edd097d31cbc74e4a3ab035d26ac2dfe6f243ea8dcbfeda99186", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0201", "normalizedDefinition": "Technology substitution depends on the task, customer and workflow segment, so aggregate company labels can conceal opposing effects.", "evidence": "Compare adoption, quality, switching and economics by segment.", "falsifier": "Uniform effects across well-defined segments weaken the need for a segmented explanation.", "limits": "Define segments before observing the outcome to reduce convenient reclassification." }, { "@id": "urn:business-engineer:source-entry:pack:181", "@type": "SourceEntry", "id": "pack:181", "sourceNumber": 181, "name": "The Definition Moved With the Number", "body": "When a headline metric is redefined in the quarter the underlying growth slowed, read the redefinition as the disclosure. Watch for: a broader product set folded into a run-rate, a shift to milestone-based reporting, a segment structure retired. Units that compound while the price attached to them does not are activity meters, not revenue leading indicators.\n- **Key Q**: \"What changed in the definition of this number, and in which quarter did the change arrive?\"", "sha256": "9f0cd484bf99a66b00db09646c204c7d169ef296eb1d7d9e011e5bc9d9df92d0", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0202", "normalizedDefinition": "A reported metric can change because its counting rule, population or period changed rather than because the underlying business improved.", "evidence": "Maintain a definition ledger and recompute comparable series where data permits.", "falsifier": "Stable definitions and reconciled denominators support a real change in performance.", "limits": "A changed definition can be legitimate; disclose its effect without assuming intent." }, { "@id": "urn:business-engineer:source-entry:pack:182", "@type": "SourceEntry", "id": "pack:182", "sourceNumber": 182, "name": "Growth Bought, Not Grown", "body": "At the application layer the financial clock arrives through the buyback, not the capex line: debt taken on to convert a flat operating business into doubled earnings per share. The guidance tell is a raise smaller than the marks already banked. Strip the marks and the share count before crediting the growth.\n- **Key Q**: \"How much of this earnings growth is operating, how much is a mark, and how much is a smaller share count bought with debt?\"", "sha256": "13f089a90fee94a46c928e30ca60d1b7cd3d7dd675a15da5d07e4c002045ab0d", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0203", "normalizedDefinition": "Changes in earnings per share can arise from operations, financing, taxes, marks and share-count changes with different durability.", "evidence": "Bridge net income and weighted shares to EPS, separating operating and non-operating components.", "falsifier": "Stable share count and clean operating improvement weaken a financial-engineering explanation.", "limits": "Buybacks are not automatically value creating; price paid, financing and alternatives matter." }, { "@id": "urn:business-engineer:source-entry:pack:183", "@type": "SourceEntry", "id": "pack:183", "sourceNumber": 183, "name": "Hedge the Displacement", "body": "An incumbent long equity in the layer taking its interface will report earnings carried by the revaluation of that stake. Hedge or admission is the open question; the structural fact is that the displacement is being monetized by the displaced. Do not assert the attribution of an undisclosed gain.\n- **Key Q**: \"Is this company's profit coming from the business or from its stake in the thing replacing the business?\"", "sha256": "9f70058d65ebf9a93de9fb59fbc1e6afc2c8326b5ee582d10f41446dac64ce64", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0116", "normalizedDefinition": "An investment position may offset or amplify weakness in a firm's operations, creating two distinct earnings and exposure channels.", "evidence": "Reconcile operating results, realized returns, unrealized marks and correlated risks.", "falsifier": "Low economic offset in stressed scenarios weakens the hedge interpretation.", "limits": "A reported gain does not necessarily supply cash or make the operating business healthy." }, { "@id": "urn:business-engineer:source-entry:pack:184", "@type": "SourceEntry", "id": "pack:184", "sourceNumber": 184, "name": "The Dependency Is a Variable, Not a Verdict", "body": "A channel governed by one discretionary counterparty can tighten or loosen in either direction, and the same counterparty may pay for the data while gating the traffic. The risk is the dependency itself, not the current direction. The rational move is to build the owned front door regardless of which way the counterparty leans this quarter.\n- **Key Q**: \"Who holds discretion over this channel, and is the response to their current mood or to the dependency?\"", "sha256": "e5a0f5abad15f9bd5c6317b09c6e417df8f1bb64e5a42bbd7503853849931aaa", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0140", "normalizedDefinition": "Compare how badly each party needs the relationship and how cheaply each can replace it.", "evidence": "Price alternatives, transition time, concentration and critical dependencies on both sides.", "falsifier": "Comparable credible alternatives weaken an asymmetric-power diagnosis.", "limits": "Dependency varies by workload and can change after integration." }, { "@id": "urn:business-engineer:source-entry:pack:185", "@type": "SourceEntry", "id": "pack:185", "sourceNumber": 185, "name": "The Rented Front Door, One Layer Down", "body": "A rail that monetizes agentic demand still depends on agent channels owned by rivals, the same discretionary counterparties that gate the taxed side of the web. Durability comes from an open standard, depth in the settlement, and the irreducibility of clearing. If a frontier agent owns checkout, the rail is disintermediated.\n- **Key Q**: \"Whose front door does this rail sit behind, and what stops that door owner from owning the settlement too?\"", "sha256": "791a67af03bbeae2bacd7505acab92cc50e19ec905e18cd2b52a7c6a6b42a595", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0140", "normalizedDefinition": "A distribution partner can gain bargaining power when a supplier depends more on its channel than it depends on that supplier.", "evidence": "Compare customer reach, substitution, direct access and switching economics for both parties.", "falsifier": "Strong direct demand or indispensable supply can overturn the channel-power thesis.", "limits": "Distribution scale alone does not establish control." }, { "@id": "urn:business-engineer:source-entry:pack:186", "@type": "SourceEntry", "id": "pack:186", "sourceNumber": 186, "name": "The Free User Is a Cost", "body": "On the web the free user was an asset with near-zero marginal cost whose attention was sold. In the AI era every free query consumes inference, so the free user is a cost until paid. The wedge is paid from day one, the metric is the outcome, and the enterprise pays first. The era's consumer-scale surface is the discovery line, reached by being cited.\n- **Key Q**: \"Is this company's free tier an asset it monetizes elsewhere or a bill it has not yet found a payer for?\"", "sha256": "3a31c3c6ff728d00ad7ca0978003ec5802d13df8c9e33114e820853a7775da9b", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0204", "normalizedDefinition": "A free user creates costs and potential future value; evaluate acquisition, conversion, learning and network benefits against actual delivery expense.", "evidence": "Measure cohort contribution, conversion, retention, compute and support cost over a stated horizon.", "falsifier": "Profitable conversion or network effects can justify a free tier despite positive marginal cost.", "limits": "Paid-from-day-one is an option, not a universal requirement; web products also had costs." }, { "@id": "urn:business-engineer:source-entry:pack:187", "@type": "SourceEntry", "id": "pack:187", "sourceNumber": 187, "name": "The Deflation Paradox", "body": "Price per unit of intelligence falls by an order of magnitude a year while tokens per task rise faster. Total spend rises as unit price collapses. Budget in tokens per accepted outcome, never in price tables; the operating response to deflation is more work per task, not less spend.\n- **Key Q**: \"As the unit price of this intelligence falls, are tokens per task rising faster, and is the budget denominated in outcomes?\"", "sha256": "06067ab01643e5a6fc16757b09e744b7989577338d550f64673447009c0b228d", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0134", "normalizedDefinition": "Lower cost per unit may expand usage, but total spending depends on how strongly demand responds and where savings are retained.", "evidence": "Estimate price changes, volume response and contribution margin with alternative elasticity scenarios.", "falsifier": "Weak volume response refutes a claim that efficiency necessarily increases spending.", "limits": "Separate technical efficiency from customer price and from total market expenditure." }, { "@id": "urn:business-engineer:source-entry:pack:188", "@type": "SourceEntry", "id": "pack:188", "sourceNumber": 188, "name": "The Three-Column Ledger", "body": "Old web, old software, new software on nine rows: unit of sale (attention / seat / accepted outcome), cost of goods (~0 / ~0 / inference), gross margin (property / property / performance), price, customer shape (crowd / median / tail), the free user (product / asset / cost), moat, balance sheet, metric. Two rows carry the meaning: the cost of goods returned, and the customer changed shape.\n- **Key Q**: \"In which column does this business sit on each row, and which two rows changed?\"", "sha256": "564e64aedaabd5ded0270d54abb7e7b07b51f40d2e0e1df310dada23f1cdc31c", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0205", "normalizedDefinition": "Compare revenue architectures through consistent payer, unit, cost, distribution, retention, control and capital assumptions.", "evidence": "Populate a common comparison table using the same period and definitions for each architecture.", "falsifier": "Unreconciled units or omitted costs make an apparent advantage non-comparable.", "limits": "The nine rows are unit of sale, cost of goods, gross margin, price, customer shape, free user, moat, balance sheet and metric; populate observations rather than assuming era-wide economics." }, { "@id": "urn:business-engineer:source-entry:pack:189", "@type": "SourceEntry", "id": "pack:189", "sourceNumber": 189, "name": "The Data Oil and the Second Barrel", "body": "The web's most valuable asset was the one it gave away: free content crawled under norms written for indexing became the corpus; value was captured at the refinery; creators were paid in traffic the models learned to make unnecessary. The settlement is late and a fraction. The wells thin under recursion, and the second barrel is the firm's residue: decision records, adjudicated cases, unavailable to any refinery that does not hold the loop.\n- **Key Q**: \"Who refined this firm's first barrel, and is the second barrel priced and owned before the first runs out?\"", "sha256": "dbf52f1f5d97045467e61e47d9453616e5b1abfb6dfa228616a039d1fdf81567", "sourceCategory": "XIX. INCIDENCE AND SUBSTITUTION AT THE TOP OF THE STACK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0206", "normalizedDefinition": "Value from widely available informational inputs can accrue to the intermediary that organizes or distributes them; privately generated decision records may create a different opportunity for retained value.", "evidence": "Trace input rights, contributor compensation, traffic or other exchange benefits, intermediary economics and the ownership and substitutability of operating records.", "falsifier": "Contributors retaining bargaining power or intermediaries unable to capture incremental value weaken the appropriation thesis.", "limits": "The web-history and recursive-data claims are case hypotheses requiring evidence. Decision records are not automatically unique, owned, lawful to reuse or economically valuable." }, { "@id": "urn:business-engineer:source-entry:pack:190", "@type": "SourceEntry", "id": "pack:190", "sourceNumber": 190, "name": "The Harness Is a Router", "body": "Value migrates up to the harness, and inside the harness it concentrates on routing. The model was the heart of the old harness; the routing junction is the heart of the new one. Routing is a six-axis problem (model, stage, hardware, cost, jurisdiction, policy), and a firm routing only across models misses most of the cost surface.\n- **Key Q**: \"Where in this stack is the routing decision made, on how many axes, and who owns the rules that make it?\"", "sha256": "25b2946ea7eedabb1ad8f03d1ea768346598f40a8435c7940d896b80c4a9a500", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0207", "normalizedDefinition": "Routing spans model choice, execution stage, hardware, cost, jurisdiction and policy. Choose among feasible allocations using quality, latency, total cost, authority and risk criteria.", "evidence": "Map the six source dimensions separately from selection criteria, then compare routed outcomes against a fixed-allocation baseline.", "falsifier": "A simpler allocation with equivalent accepted quality, compliance and lower overhead weakens the routing advantage.", "limits": "The six dimensions are a useful design inventory, not a universal optimization formula; value need not concentrate in the router." }, { "@id": "urn:business-engineer:source-entry:pack:191", "@type": "SourceEntry", "id": "pack:191", "sourceNumber": 191, "name": "Routing Is Fractal", "body": "The same pattern recurs at every altitude: compute fabric routes workloads in nanoseconds, the harness routes queries in milliseconds, the depth stack routes per deployment, an independence integrator routes vendors per engagement, a coalition routes narrative over years. The moat at each altitude is the private logic deciding which end to call.\n- **Key Q**: \"At which altitude is this router operating, and what does the same pattern look like one rung up and one rung down?\"", "sha256": "a54f175310ff82b518542abb2490e3264a61dcca2bf546795a511fb911914077", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0208", "normalizedDefinition": "Resource-allocation patterns can recur at task, workflow, team and firm levels, but the authority and feedback at each level differ.", "evidence": "Match the allocation mechanism, decision rights and feedback speed before transferring a routing analogy.", "falsifier": "A mismatch in authority or observability invalidates the cross-scale transfer.", "limits": "This is a comparative lens, not proof that all scales follow one fractal law." }, { "@id": "urn:business-engineer:source-entry:pack:192", "@type": "SourceEntry", "id": "pack:192", "sourceNumber": 192, "name": "The Owned/Rented Barbell (The Alpha-Writing Sort)", "body": "Own the deep substrate and the routing junction; rent the middle. The most expensive position is the middle: renting everything while owning nothing that compounds. Sort workloads by one question: does this write the firm's edge? If yes, own it on open weights; if no, rent the closed frontier and never look back.\n- **Key Q**: \"Does this workload write my edge, and if so, is it running on something I own?\"", "sha256": "fce30dc13f52aa55dbc4bc9f4ad0d4e94a604662a44f8e7f4f4eb05ea2af4440", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0135", "normalizedDefinition": "Combine controlled durable assets with rented capabilities when this improves economics, adaptability and bargaining options.", "evidence": "Compare title, operating rights, maintenance, switching and alternative-execution costs for each layer.", "falsifier": "Higher total cost or brittle integration can defeat the proposed ownership mix.", "limits": "Open weights do not automatically provide IP ownership or freedom from dependency." }, { "@id": "urn:business-engineer:source-entry:pack:193", "@type": "SourceEntry", "id": "pack:193", "sourceNumber": 193, "name": "The Co-Adaptation Principle", "body": "Model, harness, and context are a loop, not a hierarchy. Performance is the fit between them, and the fit can be tuned without retraining the model. Harness tuning at a fraction of the cost can close most of a capability gap; the search space a cheaper model affords is itself a capability.\n- **Key Q**: \"Am I improving the model, or the fit between model, harness, and context, and which one is cheaper to move?\"", "sha256": "93eb40a9e0f057eb9eb5243e73c63df888c6f4ccdcf206615855b02648c30666", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0209", "normalizedDefinition": "System performance depends on interactions among the model, orchestration, context, tools and evaluation design.", "evidence": "Test component changes and combinations on representative tasks with equal resource accounting.", "falsifier": "No interaction effect or a simpler configuration matching results weakens a co-adaptation thesis.", "limits": "A successful benchmark configuration may not generalize to new tasks or releases." }, { "@id": "urn:business-engineer:source-entry:pack:194", "@type": "SourceEntry", "id": "pack:194", "sourceNumber": 194, "name": "The Exhaust Flywheel", "body": "Traces, evaluations, harness configuration, and memory are next turn's fuel, and they exist nowhere but the deployment that produced them. The moat of a super agent is its exhaust. A closed frontier condenses that exhaust into the landlord's weights and redistributes it; an open harness keeps the flywheel inside the firm's walls.\n- **Key Q**: \"Where does this deployment's exhaust accumulate, and whose walls is it inside?\"", "sha256": "77c8d17bc830e6f72687a46aa9c217db59d80dce095cd2faaad7bbabf312e9e8", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0260", "normalizedDefinition": "Operational traces, adjudicated cases, evaluation results and configuration changes can improve subsequent work when permitted capture, curation and a tested learning process turn them into reusable assets.", "evidence": "Follow traces into curated cases, system changes, reuse and measured improvement across comparable decisions; identify who controls and benefits from each step.", "falsifier": "Growing records without better performance, lower rework or practical reuse weakens the flywheel claim.", "limits": "Provider training on customer data depends on contracts and settings. An open harness does not by itself guarantee retained rights, privacy or learning." }, { "@id": "urn:business-engineer:source-entry:pack:195", "@type": "SourceEntry", "id": "pack:195", "sourceNumber": 195, "name": "Depth Collapse", "body": "The artifact built for a shallow layer is the artifact the deep layer requires: a grounding graph built for retrieval is a training corpus at another depth. Firms that structured data for retrieval already own their path to a co-designed model. Depth is not how far into the model you reach; it is what you own at the bottom, what you own at the junction, and whether you can serve the difference.\n- **Key Q**: \"Which artifact built for retrieval is also this firm's training substrate, and does it hold clear title to it?\"", "sha256": "fa2ce700c50404fe1d42b2d42948da44882deccc686685fb54572405f97e879e", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0210", "normalizedDefinition": "A structured artifact created for retrieval can also support training or model adaptation if its rights, representation and quality permit reuse across those depths.", "evidence": "Test a grounding graph or retrieval corpus as adaptation data, measuring transformation effort, held-out performance, provenance and permitted uses.", "falsifier": "Large reconstruction cost, rights restrictions or no improvement on fresh tasks weakens the cross-depth reuse claim.", "limits": "Retrieval suitability does not guarantee training suitability, model ownership or a ready path to a co-designed model." }, { "@id": "urn:business-engineer:source-entry:pack:196", "@type": "SourceEntry", "id": "pack:196", "sourceNumber": 196, "name": "Restriction vs Diffusion (Openness as Demand Policy)", "body": "The axis is not closed-Western versus open-Chinese; it is whether a layer is restricted or diffused. From a supplier's seat, open weights are demand policy: openness at every layer below a junction raises the value of the junction. Tiers stratify rather than substitute, and stratification multiplies routing decisions. A signature list is a map of whose economics depend on which layer staying open; the absences are the counter-coalition.\n- **Key Q**: \"Which layer does this actor want open, which does it hold, and what does the roster of absences say?\"", "sha256": "01bb38eb9a62df7454f973aac90328e146127d6f6435cff191f0df938009e5e3", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0211", "normalizedDefinition": "Opening an interface or complement can increase adoption and demand for a retained junction while leaving selected rules, assets or distribution under the firm's control.", "evidence": "Map licenses, interoperability and export rights, then measure induced adoption, demand for the retained component, monetization and switching costs.", "falsifier": "Open complements that enable substitutes without increasing profitable demand weaken the demand-policy thesis.", "limits": "Open interfaces, open source and open weights grant different rights; openness need not increase rent capture." }, { "@id": "urn:business-engineer:source-entry:pack:197", "@type": "SourceEntry", "id": "pack:197", "sourceNumber": 197, "name": "The Palantir Paradox", "body": "The firm with the strongest incentive to defend lock-in signs for model portability because its capture point sits above the model layer. Best empirical proof that the enterprise-AI moat is not the model. Generalizes upward: whoever captures at the endpoint or the junction can commit to openness below at no cost.\n- **Key Q**: \"Where does this company capture, and does that let it be generous about everything beneath?\"", "sha256": "9d1bc57fe0c8f7cadb45aa7b5ee2be79c933b0ecaa7e3f6991e345eb9877efe7", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0211", "normalizedDefinition": "Use a company case to ask which interfaces are opened and which economically important functions remain controlled.", "evidence": "Verify current product terms, interoperability and switching evidence for the named case.", "falsifier": "Usable alternatives without dependence challenge the proposed boundary.", "limits": "The source's Palantir example is a historical illustration, not a verified current company fact." }, { "@id": "urn:business-engineer:source-entry:pack:198", "@type": "SourceEntry", "id": "pack:198", "sourceNumber": 198, "name": "The Absorption Line (The Sixth Risk)", "body": "Beside value, viability, usability, and feasibility sits a fifth risk (will it keep doing what it did) and a sixth: will the next release do it without you. Draw the line between perishable compensation for what the model cannot yet do and durable requirement the firm should own. Deletions are progress; the harness becomes a meta-harness, the referee of referees.\n- **Key Q**: \"Which parts of this product compensate for a temporary gap, and which would the firm still need after the next release?\"", "sha256": "c36db6246f0d977dbb02efddb32ae85e6c83de158d68f1b1f3395546ce9df854", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0212", "normalizedDefinition": "A feature can lose independent value when an upstream platform incorporates a sufficiently good substitute into an existing distribution channel.", "evidence": "Compare roadmap evidence, task quality, bundling, customer switching and the product's retained assets.", "falsifier": "Persistent willingness to pay for differentiated workflow value weakens the absorption thesis.", "limits": "A release announcement does not prove substitution; timing and integration matter." }, { "@id": "urn:business-engineer:source-entry:pack:199", "@type": "SourceEntry", "id": "pack:199", "sourceNumber": 199, "name": "The Three-Stage Token Lifecycle (The Reasoning Tax)", "body": "Training (fabric-bound, amortized), prefill (parallel, cheap), decode (sequential, memory-bound, where the tolls sit). Reasoning and agentic loops multiply decode by 50–200x for the same user question. Cheaper models raise total decode spend because they expand what is worth asking. Value cascades to the physical floor, the distribution endpoint, and the routing junction, not the model.\n- **Key Q**: \"Which stage of the token lifecycle does this cost or moat live in, and does it scale with reasoning?\"", "sha256": "ba443eefe9d85e3f7d484db313afe43652e356513845d57fe09f8318e653a352", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0213", "normalizedDefinition": "Training, adaptation, prefill, decoding, retrieval and tool execution have different resource profiles and cost drivers.", "evidence": "Measure workload-specific throughput, latency, hardware use and cost under comparable service requirements.", "falsifier": "Different workload mixes can overturn a claimed hardware or cost advantage.", "limits": "No universal decoding ratio or annual cost-decline rate applies to every system." }, { "@id": "urn:business-engineer:source-entry:pack:200", "@type": "SourceEntry", "id": "pack:200", "sourceNumber": 200, "name": "Networking Inversion", "body": "An efficiency release can move the gate rather than open it: open weights free to download and expensive to serve relocate the binding constraint from model access to serving capacity, shrinking one interconnect bucket and inflating another. Falsify by watching where fabric demand rotates.\n- **Key Q**: \"Did this efficiency gain remove the constraint or move it, and to which physical bucket?\"", "sha256": "19114f7ebf0194c88239c904c6f0a91190f717159442fba5dfd59ddd3763bda4", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0130", "normalizedDefinition": "The limiting resource in an AI system can shift among compute, memory, interconnect, data access, power and demand.", "evidence": "Profile the workload and test throughput after relieving the suspected constraint.", "falsifier": "No performance gain or a different binding resource weakens the diagnosis.", "limits": "Vendor specifications do not establish the bottleneck in the deployed workload." }, { "@id": "urn:business-engineer:source-entry:pack:201", "@type": "SourceEntry", "id": "pack:201", "sourceNumber": 201, "name": "Product Workloads vs Capability Workloads (The Inference Cage)", "body": "A product workload is high-volume, continuous, meterable, and has an external buyer; it books revenue. A capability workload is lumpy, internal, bursty, and has one customer; it books nothing. One substrate serving both starves the second, and a merchant gradient bends the architecture toward the workload it can sell. Owning every layer lets the layer that pays overrule the layer that wins later.\n- **Key Q**: \"Which workload does this substrate's roadmap bend toward, and what does the bend crowd out?\"", "sha256": "5ce2ab5b4e2dc44155cb7f961caae6e0bf03c50cf9d1d8a1bcfa3040077a17d9", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0214", "normalizedDefinition": "Externally sold product workloads and internally consumed capability workloads can compete for a shared substrate; revenue visibility may bias allocation against internal capability.", "evidence": "Separate external and internal demand, service requirements, utilization and roadmap decisions; measure which work is delayed and the value it would create.", "falsifier": "Balanced allocation and supported internal service levels weaken a merchant-bias diagnosis.", "limits": "External work can lose money and internal work can be operational. Volume and burstiness depend on the workload, not its label." }, { "@id": "urn:business-engineer:source-entry:pack:202", "@type": "SourceEntry", "id": "pack:202", "sourceNumber": 202, "name": "The Split Is the Admission", "body": "A product line that bifurcates after years as one architecture confesses that the unified version carried a compromise. Read roadmap splits backward, and note that the admission lands years before the fix ships.\n- **Key Q**: \"What does this split confess about the years the line was unified?\"", "sha256": "81038069ac5da6b57514a19eaeb493ba860b3f6711fe4e4cc3b21d33dc4d6eb1", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0215", "normalizedDefinition": "Specialized architecture may reveal an economically important workload constraint, but its value depends on real utilization and system fit.", "evidence": "Compare representative benchmarks, total deployment costs and demand for the specialized function.", "falsifier": "A flexible alternative with comparable economics weakens the specialization advantage.", "limits": "Architecture announcements are evidence of a bet, not proof of a new market regime." }, { "@id": "urn:business-engineer:source-entry:pack:203", "@type": "SourceEntry", "id": "pack:203", "sourceNumber": 203, "name": "The Option to Iterate (Rationing Reprices the Bench)", "body": "The binding constraint on frontier research is compute available now, not in aggregate; measure it in queue latency, not chips. Rationing changes the return on staying for exactly the people with the most options. Compute allocation is a talent policy whether intended as one or not, and the first casualties are the strongest names.\n- **Key Q**: \"What is this lab's queue latency, and who leaves first when it lengthens?\"", "sha256": "cf65fed4b0c2db143ffff1b8d2671f20b6a58b42164f8d40e35da9598db3cc85", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0216", "normalizedDefinition": "Access to tools, compute, users and fast feedback can affect expert learning speed and the attractiveness of an organization.", "evidence": "Compare time to experiment, feedback quality, autonomy and retention reasons across teams.", "falsifier": "Compensation, management or mission explaining departures better weakens the iteration-access hypothesis.", "limits": "Do not infer individual motives from infrastructure differences alone." }, { "@id": "urn:business-engineer:source-entry:pack:204", "@type": "SourceEntry", "id": "pack:204", "sourceNumber": 204, "name": "The Second Index (Structuring Is Ownership)", "body": "The competency that wins a corpus is industrializing its structuring, not the intelligence on top. Usage is the substitute signal where a corpus does not self-describe, but it reaches only data already in use (the cold corpus), and usage is not authority. The encoded business logic is the unit of capture; exit stops being migration and becomes rebuild. The open format is a solvent on rivals' lock-in and a funnel into your own index. The consultant becomes a subscription.\n- **Key Q**: \"Who is building the graph over this corpus, from what signal, and who holds it once built?\"", "sha256": "847df0a8906bbbe4759d1501c31320ee482898b548c64636f89966448f792358", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0217", "normalizedDefinition": "A maintained representation of entities, meanings and relationships can become a valuable control point when workflows depend on its accuracy and portability.", "evidence": "Test semantic completeness, maintenance, provenance, query usefulness and export into an alternative runtime.", "falsifier": "Cheap reconstruction with equivalent performance weakens a durable-index advantage.", "limits": "Owning a graph does not by itself create a moat or authority to act." }, { "@id": "urn:business-engineer:source-entry:pack:205", "@type": "SourceEntry", "id": "pack:205", "sourceNumber": 205, "name": "The Only Door (The Four Planes)", "body": "A model knows nothing but what it reads, and at the moment of use it reads only the window. Capability, cost, and governance are all decided at one aperture. Application, execution, and governance planes read through the context plane; a rule not in the window is not a rule, and a rule only in the window is not enforced. Policy holds in the substrate and the runtime, not the prompt.\n- **Key Q**: \"What does this agent actually read at the moment of action, and where is the policy enforced if not there?\"", "sha256": "44ba154d24c62b98bcb9a88af1a60d4b00a17bde651bf51250a5e4f7a9fddaab", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0218", "normalizedDefinition": "Distinguish application interaction, context and knowledge, execution, and governance to assign responsibilities and locate failure boundaries.", "evidence": "Trace a task across the four functions, including external controls and feedback.", "falsifier": "Unmapped responsibilities or boundary failures show that the chosen decomposition is incomplete.", "limits": "These are functional planes, not a universal implementation standard or chronological stack." }, { "@id": "urn:business-engineer:source-entry:pack:206", "@type": "SourceEntry", "id": "pack:206", "sourceNumber": 206, "name": "The Attack Surface Is the Window", "body": "Injection is a context failure: instruction and fact look identical in the window. Defense is provenance on the fact, data marked as data, permission on the read, scope on the tool, a gate on the write, and attenuation across every hand-off (permissions only narrow). Memory is persistent injection risk. Forgetting is a property of the substrate, not the model.\n- **Key Q**: \"Which of the five gates does this window lack, and can a child agent reach more than its parent?\"", "sha256": "f01aa03f9e00497e8221d4684513868eb84e332be04ce4ccbab81292c87681ff", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0219", "normalizedDefinition": "A system's use of information and delegated actions requires explicit boundaries between instructions, untrusted content, credentials and authorized execution.", "evidence": "Inspect trust labels, permission checks, external enforcement and adversarial task tests.", "falsifier": "Unauthorized action or untrusted content overriding authority refutes the claimed boundary effectiveness.", "limits": "Models contain learned information beyond the context window; enforcement need not reside inside the model." }, { "@id": "urn:business-engineer:source-entry:pack:207", "@type": "SourceEntry", "id": "pack:207", "sourceNumber": 207, "name": "The Two Readers", "body": "Humans ask by query; agents ask by description. The shape of the store decides the question it can answer (by key, by similarity, by reference, by description and traversal). A fact by traversal costs hundreds of tokens; by similarity, thousands. The domain expert signs the vocabulary; an ontology the business does not recognize is a schema. Answer engines outside the firm read the same substrate, so entity clarity is one piece of work done once.\n- **Key Q**: \"Is this store shaped for the question the agent asks, and did the business sign the vocabulary it uses?\"", "sha256": "609c69e315cb7868a165fd84237dd40a901bb67f4b51fec19c1533e2c1da0e08", "sourceCategory": "XX. THE INTELLIGENCE STACK — ROUTING, HARNESS, CONTEXT, MODELS (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0220", "normalizedDefinition": "A knowledge store's representation and retrieval methods determine which human or agent questions it can answer accurately and efficiently; domain-approved vocabulary helps preserve business meaning.", "evidence": "Compare key lookup, similarity, reference and graph traversal on representative queries; measure answer quality, latency and cost and obtain domain-owner review of the vocabulary.", "falsifier": "Equivalent performance from a simpler representation or domain disagreement about the encoded meaning weakens the proposed semantic design.", "limits": "Humans and agents can use several query forms. Token-cost comparisons are workload-specific; a business-approved vocabulary is neither sufficient validation nor a requirement for a graph to be technically an ontology." }, { "@id": "urn:business-engineer:source-entry:pack:208", "@type": "SourceEntry", "id": "pack:208", "sourceNumber": 208, "name": "Goodhart Is the Physics", "body": "Reward hacking, specification gaming, judge exploitation, sycophancy, benchmark contamination, and sandbagging are one literature with five names. Any measure a loop can see, the loop will optimize. Treat this as physics, not as a bug class, and design every instrument so the loop cannot see it.\n- **Key Q**: \"Can the thing being optimized see the measure I am using to judge it?\"", "sha256": "ebf9458c293f75a507738c8c6615c0b8761b7b4bfb6c5df6bc56b5dfeeea566c", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0221", "normalizedDefinition": "Optimizing a proxy can reduce its usefulness when behavior exploits the gap between the measure and the intended outcome.", "evidence": "Compare proxy gains with independent outcome measures, adversarial cases and distribution shifts.", "falsifier": "Sustained outcome improvement on fresh cases weakens a metric-gaming explanation.", "limits": "Goodhart effects, contamination, sycophancy and deceptive behavior are distinct hypotheses, not one physical law." }, { "@id": "urn:business-engineer:source-entry:pack:209", "@type": "SourceEntry", "id": "pack:209", "sourceNumber": 209, "name": "The Frozen Suite", "body": "The one measure the loop cannot see: real cases, adjudicated by domain experts, frozen before the build, held out, versioned, model-agnostic. Grown by logged addition, frozen per version. Right for the right reasons predicts the next version; a passing score alone does not.\n- **Key Q**: \"Is there a referee this loop cannot see, and was it frozen before the loop started?\"", "sha256": "b3f6d3bdf4664b07d155ab91cbad61b7dde7a615c95c170332de58cb21a988fb", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0222", "normalizedDefinition": "A system needs an outcome standard and evaluation process sufficiently independent of its optimization process to detect real failures.", "evidence": "Use versioned holdouts, fresh cases, contamination checks, adversarial tests and live outcome monitoring.", "falsifier": "High suite performance with repeated live failure weakens the suite's validity.", "limits": "A frozen or secret suite alone is insufficient; independence is proportionate to risk and may include external review." }, { "@id": "urn:business-engineer:source-entry:pack:210", "@type": "SourceEntry", "id": "pack:210", "sourceNumber": 210, "name": "Evaluation Is the Specification (The Model Chosen Last)", "body": "Behaviour is specified by adjudicated example: the golden set is the requirements document, thresholds are the acceptance criteria. Choose the model last, in the final week, because by then the suite exists to choose it with. Vendor benchmarks say nothing about your cases.\n- **Key Q**: \"Does this product have a specification a model can be graded against, and was the model chosen before or after it existed?\"", "sha256": "d0ab9331e58235c3bbde409c3aec8d928ec6505df9aa8a33655fe2195f84d704", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0223", "normalizedDefinition": "Specify observable acceptable behavior, failure handling and authority boundaries before treating a demonstration as successful delivery.", "evidence": "Write representative cases, thresholds, exception paths and acceptance responsibilities before the proof.", "falsifier": "Repeated disagreement among qualified evaluators exposes an underspecified standard.", "limits": "Requirements and feasibility co-evolve; model selection need not wait until the last week." }, { "@id": "urn:business-engineer:source-entry:pack:211", "@type": "SourceEntry", "id": "pack:211", "sourceNumber": 211, "name": "Cost per Accepted Outcome (The Third Bottleneck)", "body": "Tokens, then compute, then attention: the one bottleneck you cannot buy. Spend tokens to save attention; the attention bill is yours. Denominate everything in cost per referee-accepted outcome, never per token or per seat, and grade value maxing, not token maxing.\n- **Key Q**: \"What does an accepted outcome cost in tokens, compute, and human attention, and which of the three is binding?\"", "sha256": "5ec4a150b6f16c9fff1a7379ce28c90f61346ec58f01ff749d38c3cb1dadcdfd", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0157", "normalizedDefinition": "Measure the full cost of producing an outcome that passes a defined acceptance standard, including failed attempts and necessary review.", "evidence": "Reconcile inference, tools, people, retries and operating overhead with accepted outcomes in the same period.", "falsifier": "A changed acceptance threshold or omitted rework invalidates a claimed unit-cost improvement.", "limits": "Keep quality, latency and outcome mix comparable; a token price is not an outcome cost." }, { "@id": "urn:business-engineer:source-entry:pack:212", "@type": "SourceEntry", "id": "pack:212", "sourceNumber": 212, "name": "The Loop as the Unit", "body": "Persistent context plus delegation plus triggers is a loop. The loop, not the prompt or the model, is the unit of engineering, ownership, and value. Bound it, instrument it, own it; the engineer who polls is the scheduler, router, and memory the loop should have had.\n- **Key Q**: \"Is this a loop the firm owns, or a person doing the loop's job by hand?\"", "sha256": "f07e1f91511eb007a5634cb24fa0f443d10bbd533abd588ab293462f3d0745fb", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0224", "normalizedDefinition": "Connect a stated outcome, evaluation standard, authorized execution and observed feedback in a repeatable loop with an accountable owner.", "evidence": "Trace outcome, decision, action, evidence, exception and update for representative cases.", "falsifier": "Unowned exceptions or missing feedback break the claim of a governed loop.", "limits": "Automation is optional; the loop can include human decisions and external controls." }, { "@id": "urn:business-engineer:source-entry:pack:213", "@type": "SourceEntry", "id": "pack:213", "sourceNumber": 213, "name": "Gross Margin as a Design Outcome", "body": "In this era margin is built, not given. Four levers: the routing table, the cache hit rate, the owned-model share, and attention per outcome. A lab's arc runs from making for a dollar and selling for twenty cents to a positive gross margin; an application's arc runs the same way through its own model. Report the levers pulled and the levers available, never the assumed margin.\n- **Key Q**: \"Which of the four margin levers has this company pulled, and which is still available?\"", "sha256": "946aa4f1ebdb4c44fa629a18ff25f2164b9290d1671d1035b5d40f68b49ec8c9", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0225", "normalizedDefinition": "Operational design can change unit cost through routing, caching, batching, retrieval, review and exception handling.", "evidence": "Measure each intervention's incremental cost, accepted quality and realized volume against a baseline.", "falsifier": "Savings erased by maintenance, rework or quality loss weaken the margin-improvement thesis.", "limits": "Available levers are not realized savings; report implementation costs and dates." }, { "@id": "urn:business-engineer:source-entry:pack:214", "@type": "SourceEntry", "id": "pack:214", "sourceNumber": 214, "name": "Pricing as a Finance Instrument (Price the Tail)", "body": "Price on attribution and autonomy, ladder by proof, never seat-price agentic value, price the compounding, and price the tail, because a small share of accounts consume most of the tokens. The incumbent's tell is the sequence seats → conversations → credits → usage.\n- **Key Q**: \"Does this price track the work done and the tail that does it, or the chairs?\"", "sha256": "8319546315b1bcf5ebfaa637c64021fca95111ee1c9eefb13b3d3f9cbd4f21dc", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0226", "normalizedDefinition": "Heavy or difficult usage can dominate service cost, making average-user economics an unreliable pricing guide.", "evidence": "Model the cost distribution, correlated peaks, retries and cohort contribution rather than only the mean.", "falsifier": "Thin stable tails and predictable usage weaken the case for special tail controls.", "limits": "Caps and pricing changes can reduce customer value; test incentives and fairness of the chosen unit." }, { "@id": "urn:business-engineer:source-entry:pack:215", "@type": "SourceEntry", "id": "pack:215", "sourceNumber": 215, "name": "Outcome Pricing Is an End State (The Hybrid Is the Transition)", "body": "Outcome pricing is right in theory and hard in practice: attribution is contested, baselines are gamed, verification lags, and the guarantee has a cost wherever it sits. The realistic path is the hybrid, seat plus credits, subscription plus metered requests, three meters at once on the record. Choose the ramp.\n- **Key Q**: \"Which rung of the seat-to-outcome ramp is this contract on, and who is carrying the guarantee's cost?\"", "sha256": "84931ed4b9afd717a826ee3e14632aa6d8ce5175280d73d9eb3ec6757398c8da", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0227", "normalizedDefinition": "Combine subscription, usage and outcome-linked charges when measurement, attribution and risk allocation support different units at different stages.", "evidence": "Test buyer acceptance, margin volatility, attribution disputes and incentives under each pricing mix.", "falsifier": "Stable economics and incentives in a hybrid can refute the need to reach pure outcome pricing.", "limits": "Outcome pricing is a possible design, not an inevitable end state." }, { "@id": "urn:business-engineer:source-entry:pack:216", "@type": "SourceEntry", "id": "pack:216", "sourceNumber": 216, "name": "The Counterfactual as Referee (Attribution Collapsed)", "body": "When the path runs through a model there is no touch to log, so last-touch attribution dies. Only incrementality survives: holdouts, geographic splits, difference-in-differences, synthetic controls. The experiment loop must be frozen like any other referee or it games itself.\n- **Key Q**: \"Is this growth claim backed by a counterfactual, or by a touch that no longer exists?\"", "sha256": "3e068994418754e94c5efcb5cdde2fefb3072913177a03c42c0d2229ed6c4d4a", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0158", "normalizedDefinition": "Distinguish observed improvement from improvement caused by the intervention using a credible baseline or comparison.", "evidence": "Use randomized, staggered or matched comparisons where feasible and record confounders.", "falsifier": "Similar gains in the comparison group weaken an attributable-value claim.", "limits": "A before-and-after gauge page alone does not establish causality." }, { "@id": "urn:business-engineer:source-entry:pack:217", "@type": "SourceEntry", "id": "pack:217", "sourceNumber": 217, "name": "Growth Goodhart (The Slop Flood)", "body": "The era adds three ways to game growth: a flood of generated content with negative return, agent-farmed activity metrics, and a self-gaming experiment loop. Only substance the machine cannot generate grows; the instruments that survive are the ones a machine cannot fake and a buyer would pay for.\n- **Key Q**: \"Could a machine have produced this growth number, and would a buyer pay for what it measures?\"", "sha256": "cc84a4fa341e0d7f07873306544700c5c83390b3d12fc25af29cb6ca67ef7ae8", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0221", "normalizedDefinition": "Growth optimization can reward activity that raises a proxy while failing to improve durable customer or economic outcomes.", "evidence": "Compare activation or usage metrics with retention, contribution and independently accepted value.", "falsifier": "Sustained improvements in those outcomes weaken a proxy-gaming diagnosis.", "limits": "A disappointing business result need not imply intentional gaming." }, { "@id": "urn:business-engineer:source-entry:pack:218", "@type": "SourceEntry", "id": "pack:218", "sourceNumber": 218, "name": "The Two Surfaces", "body": "A human sees the interface; an agent sees the specification. Same outcome, two surfaces, one suite grading both. Design for the reader who never sees the screen. Activation is the first verified outcome; retention is the outcome kept.\n- **Key Q**: \"Does this product have an agent surface, and is it graded by the same referee as the human one?\"", "sha256": "69bdb8aa1a71f1b9a3e81d67b726e497da4e56fb48b9cfc87ba5a5b1d6f2c496", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0259", "normalizedDefinition": "A product can expose a human interface and an agent specification or API over consistent business rules, permissions and state, evaluated against a shared outcome standard.", "evidence": "Run representative tasks through both surfaces and compare accepted outcomes, authorization, state changes and exception handling.", "falsifier": "Divergent business rules or success on the screen with failure through the machine interface weakens the shared-product claim.", "limits": "The surfaces need not expose identical capabilities or workflows; define activation and retention in terms of actual accepted value where useful." }, { "@id": "urn:business-engineer:source-entry:pack:219", "@type": "SourceEntry", "id": "pack:219", "sourceNumber": 219, "name": "The Residue Loop", "body": "Every accepted outcome and every adjudicated exception leaves a record: the decision loop's second output. It is the only growth loop the machines cannot mediate, the second barrel of oil, the roadmap (\"what was built twice?\"), and the basis of the owned model. Capture rate of the residue is a board number.\n- **Key Q**: \"What does this loop leave behind, who owns it, and what fraction is being captured?\"", "sha256": "0d59e5e915754f4b80e2283cc46ea21e479bcd049ce85c6c6f000182d18b5674", "sourceCategory": "XXI. MEASUREMENT UNDER OPTIMIZATION PRESSURE — THE DISCIPLINES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0260", "normalizedDefinition": "A successful work loop can deliver the immediate outcome and reusable evidence that improves later execution.", "evidence": "Measure artifact capture, curation, ownership, reuse and downstream performance separately.", "falsifier": "High capture without reuse or benefit weakens a compounding claim.", "limits": "The useful capture rate depends on task, privacy, consent and maintenance economics." }, { "@id": "urn:business-engineer:source-entry:pack:220", "@type": "SourceEntry", "id": "pack:220", "sourceNumber": 220, "name": "The Multiple Comes Last (The Five Broken Assumptions)", "body": "The software toolkit (run-rate × multiple) rests on five assumptions the era broke: run-rate is revenue (it is a month times twelve, unaudited, on the company's own basis); gross margin is a category property (it is a design outcome in motion); the product is the asset (the next release absorbs part of it); the customer pays per seat (a heavy tail pays for work); the capital is on the balance sheet (leases, guarantees, supplier equity, private credit). Each error runs in a nameable direction. The reported number is the beginning of a valuation, not its input.\n- **Key Q**: \"Which of the five assumptions is this valuation still making, and in which direction does the error run?\"", "sha256": "8ed7b11d78a48d3a91ebbcc100a4a5e6331f9a0a55ac48d27e28a2621522f181", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0228", "normalizedDefinition": "Build a valuation from reconciled revenue, cost, durability, control, funding and failure assumptions before using a market multiple as a cross-check.", "evidence": "Document a cash-flow bridge, competing valuation and sensitivity to the assumptions that explain the gap.", "falsifier": "An unresolved counting or cash-flow inconsistency invalidates precision in the headline value.", "limits": "The nine-question order is a practical workflow, not the only valid valuation method." }, { "@id": "urn:business-engineer:source-entry:pack:221", "@type": "SourceEntry", "id": "pack:221", "sourceNumber": 221, "name": "The Counted Top Line", "body": "Count each end-customer dollar once, at the tier where the customer transacted: assign the tier, strip pass-through, exclude the tier that is a cost of the tiers above, convert gross to net, convert run-rate to a year with growth decaying to a terminal rate, and state source and range. Counted-to-reported typically lands at 0.6–0.85. A gross figure in the headline is a maturity-zero disclosure.\n- **Key Q**: \"What is this company's counted top line, and what is the ratio of counted to reported?\"", "sha256": "bcb53e59628feea9d6c9127f3a3dced45a2a2252c34cbe4d69ac267344481d24", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0229", "normalizedDefinition": "Define whether the analysis counts reported company revenue, gross transactions or final-customer demand, then reconcile the chosen boundary.", "evidence": "Bridge tiers, payer classes, gross versus net treatment and run-rate versus realized annual revenue.", "falsifier": "A boundary-consistent bridge can refute an apparent overstatement caused only by unlike measures.", "limits": "Partner-funded revenue may be recognized legitimately; demand independence is a separate analysis." }, { "@id": "urn:business-engineer:source-entry:pack:222", "@type": "SourceEntry", "id": "pack:222", "sourceNumber": 222, "name": "The Residual", "body": "The fraction of a company's value on the durable side of the absorption line, after what the next release absorbs, what the supplier's mark inflated, and what the hidden obligation subtracts. A company at 70% residual is a business; at 30% it is a feature with a run-rate. The multiple is applied to the residual and to nothing else. In a residual-adjusted cash flow, the perishable share decays per release and terminal value is taken on the durable share only; a compensation with a two-release life at a six-week cadence is worth a quarter of a year, not a perpetuity.\n- **Key Q**: \"What fraction of this company survives the next release, and is the multiple being applied to that fraction or to the whole?\"", "sha256": "1c969a81a3ac9f856337544b3e80bc748149c787ac0953669da4d0b3ec23cd30", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0230", "normalizedDefinition": "Separate cash flows supported by persistent assets and relationships from those exposed to likely substitution or rapid decay.", "evidence": "Model renewal, switching, replacement and reinvestment under explicit durability scenarios.", "falsifier": "Durable retention despite anticipated substitution weakens the assumed decay rate.", "limits": "Durability is a spectrum; terminal value also depends on reinvestment, competition and sustainable growth." }, { "@id": "urn:business-engineer:source-entry:pack:223", "@type": "SourceEntry", "id": "pack:223", "sourceNumber": 223, "name": "The EV Bridge With Hidden Piers", "body": "Enterprise value is equity plus debt plus what the balance sheet hides: leases not commenced (weighted by deferral versus transfer), purchase commitments, guarantees weighted by call likelihood, supplier financing, vehicle debt, private credit. Builders and neoclouds carry hidden-obligation multiples from 1.1 to well above 1.5.\n- **Key Q**: \"What is this company's hidden-obligation multiple, and does the equity story survive it?\"", "sha256": "ce4d28c0c2ebc1e19c0cca49446d82a28847f760a54c4a197e63d828bb91acbd", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0231", "normalizedDefinition": "Reconcile operating value with equity and other claims, cash and non-operating assets, and separately identified contingent or debt-like exposures.", "evidence": "Bridge equity, debt, preferred claims, noncontrolling interests and relevant cash with consistent DCF and lease treatment.", "falsifier": "An obligation already included in cash flows or debt exposes double counting if added again.", "limits": "Not every purchase commitment is debt; avoid subtracting cash or adding liabilities twice." }, { "@id": "urn:business-engineer:source-entry:pack:224", "@type": "SourceEntry", "id": "pack:224", "sourceNumber": 224, "name": "The Worthless Cases, Weighted", "body": "A valuation without its worthless case is a bull case with a number on it. Name three: commoditisation (the model layer absorbs the product), capture (the vendor holds what compounds), the wrapper (the guarantee or the counterparty fails), each with a trigger and a probability. Sum probability times value across base and worthless cases.\n- **Key Q**: \"What kills this company, what is the trigger, and what is the probability-weighted value once that case is in the sum?\"", "sha256": "0423f85b58f7da652a5f4380a7c1e7a5a38efffcc8486bab23de3c093c752b25", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0232", "normalizedDefinition": "Identify mechanisms that can destroy or sharply reduce equity value and model their triggers, timing, recovery and probability where supportable.", "evidence": "Stress liquidity, substitution, concentration and asset recovery with explicit correlated assumptions.", "falsifier": "Adequate recovery or resilient cash flow can refute a literal worthless scenario.", "limits": "Three cases is a drafting aid; probabilities must be supported and scenarios must not be double counted." }, { "@id": "urn:business-engineer:source-entry:pack:225", "@type": "SourceEntry", "id": "pack:225", "sourceNumber": 225, "name": "The Layer Multiple and the Reconciliation", "body": "Borrow the multiple from the nearest priced asset by layer, not by category: junction, rail, application, neocloud, supplier, each has a priced comparable; the frontier lab has none, which is itself the finding. Then reconcile to the reported number by naming the question that made the gap. The company is usually real; the number often was not.\n- **Key Q**: \"From which priced layer does this multiple come, and which of the nine questions explains the gap to the reported number?\"", "sha256": "b0693fe002874db509fd05f788d07dbea9fd3bf6742cd4fa56fb482b4506b862", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0095", "normalizedDefinition": "Choose valuation comparables according to economic function, cash-flow quality, growth, risk and capital requirements.", "evidence": "Reconcile numerator, denominator, business mix and reinvestment across the comparable set.", "falsifier": "A different layer with demonstrably similar economics can outperform a superficially similar peer.", "limits": "Layer labels do not establish comparability on their own." }, { "@id": "urn:business-engineer:source-entry:pack:226", "@type": "SourceEntry", "id": "pack:226", "sourceNumber": 226, "name": "The Acqui-Hire Read", "body": "License the IP, hire the team, leave the shell: the market pricing the residual directly and leaving the company on the table. Read each such deal as a valuation of what compounds (the people and the exhaust) against what does not (the corporate entity). Place public cases on a residual axis and the pattern reads itself.\n- **Key Q**: \"In this deal, what did the buyer pay for and what did it leave behind, and what does that say about the residual of the whole company?\"", "sha256": "022b943259d639541bb6f4e06d78eaa24e72042c21db260ed2cfb4530bfaa137", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0233", "normalizedDefinition": "A transaction price is interpretable only after identifying the assets, liabilities, rights, control and contingencies actually transferred.", "evidence": "Read the deal perimeter, consideration, assumed debt, earnouts and retained obligations.", "falsifier": "Material excluded assets or contingent payments undermine a simple headline-price comparison.", "limits": "An announced valuation is not always cash consideration or enterprise value." }, { "@id": "urn:business-engineer:source-entry:pack:227", "@type": "SourceEntry", "id": "pack:227", "sourceNumber": 227, "name": "The Hostile Reading First", "body": "Before the base case, write the reading a hostile analyst would write: gross booked as net, the assumed margin, the perishable feature, the supplier's mark, the hidden obligation. If the company survives the hostile reading at a defensible number, the base case has earned its place.\n- **Key Q**: \"What would the most hostile competent reader say this is worth, and can I answer each of their questions with an artifact?\"", "sha256": "5a57dc332f5611fd2c46e14817634a0a5d1ecc82a1142fb857434227e7995444", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0162", "normalizedDefinition": "Construct the strongest credible explanation for a lower value before accepting the base case and identify evidence that distinguishes them.", "evidence": "Reconcile both cases on the same revenue boundary, capital assumptions and date.", "falsifier": "Evidence inconsistent with the hostile case should revise it rather than be dismissed.", "limits": "The hostile reading is a counter-model exercise, not a requirement to be pessimistic." }, { "@id": "urn:business-engineer:source-entry:pack:228", "@type": "SourceEntry", "id": "pack:228", "sourceNumber": 228, "name": "Read the Sign of the Distortion (Two Engines, Both Ways)", "body": "Marks distort earnings upward; stock compensation, convert-extinguishment losses, and IPO charges distort them downward. Reported net income can sit above or below the operating line, and the direction is diagnostic. Strip in both directions; never assume the distortion flatters.\n- **Key Q**: \"Does this reported number sit above or below the operating engine, and which non-cash item put it there?\"", "sha256": "69ecebadc9018b2dbb8d809e82aebe49ecef68bf3a2d9d296f576593d397df91", "sourceCategory": "XXII. VALUATION — THE NINE QUESTIONS AND THE RESIDUAL (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0116", "normalizedDefinition": "Remove or explain both positive and negative non-operating distortions when assessing operating performance.", "evidence": "Bridge reported results to the selected operating measure with symmetric inclusion rules.", "falsifier": "Selective treatment of gains and losses invalidates the comparison.", "limits": "Noncash operating costs such as stock compensation still have economic consequences." }, { "@id": "urn:business-engineer:source-entry:pack:229", "@type": "SourceEntry", "id": "pack:229", "sourceNumber": 229, "name": "The Asymmetry", "body": "The seller runs the meeting fifty times a year; the buyer runs it twice. Selling is a practiced craft, now automated; buying is an amateur sport played against professionals. Instruments substitute for the repetitions the buyer will never have. The ordering is the argument: the standard, the separated champion, and the buying function come before any vendor.\n- **Key Q**: \"What instrument does this buyer hold that substitutes for the repetitions the seller has and it does not?\"", "sha256": "7b394d8a14cfb23e033d8c156450f614ce225ba93b2169a82ee4111a0ff955c5", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0234", "normalizedDefinition": "A repeat seller may possess more information and process experience than an occasional buyer, affecting negotiation and evaluation quality.", "evidence": "Compare access to benchmarks, reference cases, contract expertise and independent verification.", "falsifier": "An experienced buyer with credible alternatives can reverse the presumed asymmetry.", "limits": "Do not infer bad faith from experience; design the process to reduce information gaps." }, { "@id": "urn:business-engineer:source-entry:pack:230", "@type": "SourceEntry", "id": "pack:230", "sourceNumber": 230, "name": "VERIFIED (The Buyer's Qualification)", "body": "The mirror of the seller's qualification alphabet: Verification owned · Economics read · Rights scheduled · Incentives separated · Feasibility on your floor · Independence priced · Exposure governed · Drift instrumented. Every letter holds an artifact, never an assurance. Run three letters before contact, three at the wedge's clock, two before signature, then annually; a failed letter prices the purchase.\n- **Key Q**: \"Which letters of VERIFIED hold an artifact, and which is the one nobody checked?\"", "sha256": "e86bf2969b03b87e9419648c3597c1206482eec6b7f20a6a57ce6e5bd04e20d6", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0235", "normalizedDefinition": "Evaluate verification, economics, rights, incentives, feasibility, independence, exposure and drift before and during a supplier relationship.", "evidence": "Require a named owner, dated artifact and disposition for each VERIFIED step.", "falsifier": "Missing artifacts or failed mandatory gates refute a claim of completed qualification.", "limits": "Price can compensate some commercial risks, but cannot cure absent required authority or a non-negotiable safety or legal gate." }, { "@id": "urn:business-engineer:source-entry:pack:231", "@type": "SourceEntry", "id": "pack:231", "sourceNumber": 231, "name": "Procurement Theater", "body": "A pilot defends a budget; a champion's advocacy is not an audit; a coached reference proves the vendor curates well; the paid map (analysts as channel, assessors selling remediation) is a channel; a board introduction is a bypass. The one test that separates theater from proof is the frozen suite on the buyer's own floor.\n- **Key Q**: \"Which part of this evaluation could the vendor have staged, and which part ran on my floor against my referee?\"", "sha256": "d0a3ec7d66c9367388c091eab9b0d64604587cff7f7096cda067e87cb226ad20", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0236", "normalizedDefinition": "Determine who selected, prepared and scored evaluation cases and which conditions differ from real buyer use.", "evidence": "Run buyer-controlled cases on representative systems with staged and unstaged conditions separated.", "falsifier": "Comparable results on fresh buyer cases weaken a procurement-theater concern.", "limits": "Vendor involvement can be useful; disclose it and preserve independent acceptance authority." }, { "@id": "urn:business-engineer:source-entry:pack:232", "@type": "SourceEntry", "id": "pack:232", "sourceNumber": 232, "name": "Fast Yes With Clean Title", "body": "The seat's answer to shadow adoption is not a slower door but a faster one with conditions: an intake measured in days that absorbs the card purchases, attaches the standard, places the junction, and prices the exit. Let go of the door; keep the four keys.\n- **Key Q**: \"Can this firm say yes in days while keeping clear title to what the purchase will compound?\"", "sha256": "23ad48183e757157e557c51761b022688a1877d551579b7a2f61a2d1a8ea7ad3", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0237", "normalizedDefinition": "Provide a rapid, visible path for evaluating and approving tools so that governance does not simply drive work into unobserved channels.", "evidence": "Measure intake time, shadow usage, incidents, adoption and coverage of approved paths.", "falsifier": "Long queues with continued shadow use refute the claim of effective governed intake.", "limits": "Speed cannot waive mandatory authorization, security or legal requirements." }, { "@id": "urn:business-engineer:source-entry:pack:233", "@type": "SourceEntry", "id": "pack:233", "sourceNumber": 233, "name": "The Enterprise Alliance (Opened vs Held)", "body": "The unit of competition is shifting from the firm to the alliance network, in three species: vendor-vendor stacks entering as one motion, substrate coalitions whose membership lists are the argument, and customer co-design where the asset is the customer's own codified expertise. Reading rule for every alliance: which layer does each ally open and which does it hold. Partner today, rival at renewal. Alliance moves lead repricing by quarters.\n- **Key Q**: \"Which layer does this ally open for me and which does it hold for itself, and where are the absences on the roster?\"", "sha256": "5e24004e575dd79f027231f6c2995f85e315c4a8694b7f17db560a7a66ade26a", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0152", "normalizedDefinition": "A partner can complement distribution or capabilities while competing for customer control, data or margin.", "evidence": "Map shared incentives, retained assets, competing offerings and exit rights.", "falsifier": "Stable aligned incentives with no material capture risk weaken an adversarial reading.", "limits": "Partnership and competition can coexist; avoid treating all alliances as traps." }, { "@id": "urn:business-engineer:source-entry:pack:234", "@type": "SourceEntry", "id": "pack:234", "sourceNumber": 234, "name": "The Hand That Wires the Harness Chooses the Landlord", "body": "Forward-deployed engineering is the capture vector: whoever wires the loop decides where the exhaust lands. When deployment labor is automated, the absorption machine is industrialized and capture gets cheaper to run at scale. A better landlord is not sovereignty; the cage moved one floor up.\n- **Key Q**: \"Who wired this loop, and whose walls does its exhaust accumulate inside?\"", "sha256": "a09636a36deec7dcd2545fcf786eeb843b637dcb56b2bdde390105eb25ad89dd", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0238", "normalizedDefinition": "Defaults chosen during implementation can become durable control points over identity, data, evaluation, workflows and future change.", "evidence": "Inventory deployed accounts, ownership, permissions, repositories, standards and export paths at handover.", "falsifier": "Buyer-controlled configuration and rehearsed migration weaken the inherited-capture thesis.", "limits": "Initial convenience does not establish permanent dependence; contracts and technical transfer both matter." }, { "@id": "urn:business-engineer:source-entry:pack:235", "@type": "SourceEntry", "id": "pack:235", "sourceNumber": 235, "name": "The Two-Hinge Window", "body": "Two hinges move in opposite directions: the funding hinge (vendor subsidy for capture) is closing, the cost hinge (open tiers collapsing the cost of alternatives) is opening and does not reverse. What expires is the subsidy, not the feasibility. Regulation with tested-exit requirements mandates the barbell in regulated industries.\n- **Key Q**: \"Which hinge is this firm timing against, the subsidy that expires or the feasibility that does not?\"", "sha256": "89a5ff44483f1c366df974fe6fea2e0c375f926053d1b6809c7758b1e6ce95fc", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0239", "normalizedDefinition": "A subsidy can accelerate adoption before dependency forms, while later substitution or repricing changes the relationship's economics.", "evidence": "Compare subsidy expiry, integration milestones, available alternatives and repricing rights.", "falsifier": "Portable deployments and sustained competitive pricing weaken a delayed-capture hypothesis.", "limits": "Introductory discounts are not proof of an intended lock-in strategy." }, { "@id": "urn:business-engineer:source-entry:pack:236", "@type": "SourceEntry", "id": "pack:236", "sourceNumber": 236, "name": "The Independence Integrator (The Double Objective)", "body": "A regime-agnostic deployment firm that turns vendor land-grab budgets into enterprise independence: column A the vendor pays for, column B the enterprise owns, same engagement. A six-week migration test at production scale is the proof; independence certification is the payday; exit is the payday, not the risk. Doctrine is the hiring filter, and the talent and the toolkit must both pass the portability test.\n- **Key Q**: \"Does this engagement leave the enterprise able to migrate in six weeks, and who gets paid when it can?\"", "sha256": "8064c95d9c0577ce3fab10c841819969d483199bfd6a5a24e1aecf21a050246e", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0240", "normalizedDefinition": "A service provider can create value by leaving the client with usable artifacts, skills and a priced exit rather than maximizing dependence.", "evidence": "Inspect retained artifacts, client competence, recurring support needs and exercised alternate execution.", "falsifier": "A technically documented exit requiring a practical rebuild weakens the independence claim.", "limits": "Independence has maintenance costs; a services relationship can remain economically sensible." }, { "@id": "urn:business-engineer:source-entry:pack:237", "@type": "SourceEntry", "id": "pack:237", "sourceNumber": 237, "name": "The Three Cages", "body": "Model, cloud, platform: three cages an enterprise can be captured in, each with its own exit cost. The regulated-industry wedge (single-vendor-risk prohibitions, budget scale, institutional patience) is where the cages get priced first. Sovereignty productized (the customer owns the weights, the vendor owns the junction) is the correct doctrine implemented at the layer that happens to be the vendor's own.\n- **Key Q**: \"In which of the three cages is this enterprise, and is the sovereignty it was sold the customer's or the vendor's?\"", "sha256": "a88bef3827586b5b98ce0502ae71e769a11983f5f8433372eac68efd97e668c4", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0241", "normalizedDefinition": "Assess dependency separately in data, semantics, runtime, model, control, commercial terms and operating skills.", "evidence": "Perform a workload-specific exit and replacement inventory with rights, costs and timing per layer.", "falsifier": "Successful transfer of one layer does not refute dependence elsewhere; a complete alternative path does.", "limits": "Open source at one layer does not make the whole system independent." }, { "@id": "urn:business-engineer:source-entry:pack:238", "@type": "SourceEntry", "id": "pack:238", "sourceNumber": 238, "name": "The Enterprise Edge as Distribution", "body": "As fine-tuning moves on-premises onto enterprise silicon, the enterprise itself becomes a distribution channel for the silicon vendor, one the vendor could not open alone. The governable software layer is the business-model wrapper that makes the sale legible; the junction owner and the silicon vendor coordinate by coincidence of interest, not alignment.\n- **Key Q**: \"Which vendor's silicon does this enterprise stack distribute, and who wrapped it into something buyable?\"", "sha256": "340c7b6e49e2b7821ce48eb3f8ca5f152c5e238f83a283d3542b113feddc0d2b", "sourceCategory": "XXIII. THE ENTERPRISE — BUYING, CAPTURE, ALLIANCES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0242", "normalizedDefinition": "An enterprise can supply demand, workflow access and trusted distribution that help a technology provider commercialize a capability.", "evidence": "Trace the provider's incremental reach, conversion and retained control through the enterprise relationship.", "falsifier": "Little incremental demand or readily substitutable access weakens the distribution-complement thesis.", "limits": "The enterprise may capture substantial value too; dependence must be assessed in both directions." }, { "@id": "urn:business-engineer:source-entry:pack:239", "@type": "SourceEntry", "id": "pack:239", "sourceNumber": 239, "name": "The Neutral Gain", "body": "Every dashboard green, margin unchanged: everyone got faster, nobody got ahead. Symmetric tools produce a neutral gain unless the firm adds asymmetric inputs or an asymmetric organization. Operational effectiveness is not strategy; with symmetric tools it is arithmetic.\n- **Key Q**: \"Your people are faster. Is the firm ahead, and by what asymmetry?\"", "sha256": "006f347c123f5f29c167e70e5096de3e0abcdbf71aaf91c014721016b200f660", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0243", "normalizedDefinition": "An absolute productivity gain does not ensure competitive advantage if peers gain similarly or customers capture the savings.", "evidence": "Compare quality-adjusted throughput, cost, price and share against a relevant peer or counterfactual.", "falsifier": "Durable relative improvement and retained margin can support an advantage beyond a neutral gain.", "limits": "Industry-wide gains can still benefit customers and workers without creating excess firm profits." }, { "@id": "urn:business-engineer:source-entry:pack:240", "@type": "SourceEntry", "id": "pack:240", "sourceNumber": 240, "name": "The Ascent Through Scales", "body": "The gain must climb four scales (individual → group → organization → strategy) and evaporates at every scale it fails to climb. The escape at each level is one level up. Track the climb, not the tool count.\n- **Key Q**: \"At which scale did this firm's gain stop climbing, and what would carry it one level up?\"", "sha256": "4e8159f59f0f09e5b350acd783c05348a94f02db56a9eaaa85baee7248a5b0b0", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0244", "normalizedDefinition": "Task gains affect firm performance only when workflow, organizational and business-model constraints allow the gains to propagate.", "evidence": "Measure task time, end-to-end throughput, operating outcomes and economic capture on aligned dates.", "falsifier": "A task improvement with no downstream change identifies a broken transmission link.", "limits": "Task, workflow, firm and market are analytical scales, not a mandatory maturity sequence." }, { "@id": "urn:business-engineer:source-entry:pack:241", "@type": "SourceEntry", "id": "pack:241", "sourceNumber": 241, "name": "Edges Find and Cannot Choose; Center Chooses and Cannot Find", "body": "Bottom-up discovery is fuel, not vehicle: it cannot rank, it fragments, it leaks. Top-down direction allocates, standardizes, and directs but cannot find. Governance is the transmission between them: a paved road measured by coverage not policy, a discovery pipeline measured by conversion time, a junction map, and a residue rule.\n- **Key Q**: \"What is this firm's conversion time from an edge discovery to a governed loop, and who owns the paved road?\"", "sha256": "e43c8155437765b03888fca635bde97fc21d1b6597fe36d08d48b77487a077a2", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0245", "normalizedDefinition": "Local experimentation can coexist with shared standards, reusable infrastructure and explicit responsibility for common constraints.", "evidence": "Compare discovery speed, duplication, paved-path use, exceptions and cross-team reuse.", "falsifier": "Central delay or uncontrolled fragmentation can refute the chosen balance.", "limits": "The appropriate center varies with risk, heterogeneity, scale and capabilities." }, { "@id": "urn:business-engineer:source-entry:pack:242", "@type": "SourceEntry", "id": "pack:242", "sourceNumber": 242, "name": "Installation Is the Entry Fee, Reorganization Is the Harvest", "body": "The dynamo took forty years because factories kept the line shaft; the harvest came with unit drive and the rebuilt floor. Today's line shaft is the workflow built around scarce human attention as the central power source. The forty-year lesson runs on a five-year clock.\n- **Key Q**: \"Has this firm installed the technology or rebuilt the floor around what it makes cheap?\"", "sha256": "63b74c1f41baca8d42221edd26b19826feff04a4453678372b4d334536744f08", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0246", "normalizedDefinition": "Technology creates more value when workflows, incentives, skills and decision rights are adapted to use it effectively.", "evidence": "Compare similar deployments with different complementary changes and account for selection effects.", "falsifier": "Equal outcomes without the proposed complement weaken its claimed necessity.", "limits": "Complementarity does not imply that every organization needs a full reorganization first." }, { "@id": "urn:business-engineer:source-entry:pack:243", "@type": "SourceEntry", "id": "pack:243", "sourceNumber": 243, "name": "Automation or Enhancement Is a Deployment Choice", "body": "Substitute versus amplify is a property of the deployment, not the model. Labor evidence shows recomposition rather than disappearance: exposure and augmentability form a diagonal, the mix moves before the total, and the missing first rung is where the damage concentrates. Design the task line with both spans and the entry gap in view.\n- **Key Q**: \"On this task line, which spans are automated, which enhanced, and where does the next person enter?\"", "sha256": "43645e84c65fabd6c8b06b8d8b587d8b934036661a8886192577e29ef451a1ed", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0247", "normalizedDefinition": "Analyze which tasks can be automated, assisted or redesigned while distinguishing task changes from whole-job outcomes.", "evidence": "Observe quality, demand, new tasks, supervision and labor allocation before and after adoption.", "falsifier": "Persisting expert requirements or expanded demand can overturn simple replacement forecasts.", "limits": "A task capability demonstration is not a headcount prediction." }, { "@id": "urn:business-engineer:source-entry:pack:244", "@type": "SourceEntry", "id": "pack:244", "sourceNumber": 244, "name": "The Ratio Rule (Push Until the Gate Bends)", "body": "Raise the agent-to-human ratio until the quality gate bends, then step back one notch. A ratio without a measured gate is refused. Public reversals (support reopened to humans after quality bent) are the rule stated in the wild.\n- **Key Q**: \"Is this ratio backed by a measured gate, and at what ratio did the gate last bend?\"", "sha256": "6d4724bb4fc0b0aaa6b2031b27c49386b56e97443f2d9a4ee7b42bce82e801a8", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0248", "normalizedDefinition": "Set a team's span of agent-supported work according to measured quality, exception load, supervision and accountability.", "evidence": "Measure accepted throughput, incidents, adjudication burden and response capacity before changing ratios.", "falsifier": "Rising unresolved exceptions or quality loss refutes a claimed safe expansion of span.", "limits": "No universal human-to-agent ratio is supplied; headcount alone is not a performance gauge." }, { "@id": "urn:business-engineer:source-entry:pack:245", "@type": "SourceEntry", "id": "pack:245", "sourceNumber": 245, "name": "The Import Test", "body": "Before importing another firm's mechanism, ask three questions: same scale, same gate, same dates. Import the mechanism; rebuild the numbers on your own floor. Revenue per employee conflates leverage with layoffs; a stale headcount violates same-dates.\n- **Key Q**: \"Does this case pass same scale, same gate, same dates, or am I importing a headline?\"", "sha256": "89663ec1cfcc6033d9f2404456b3c0531f5320af9a3a8c87f21937f2805ab8a6", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0167", "normalizedDefinition": "Transfer an external case only after matching the mechanism, scale, measured gate and date to the local decision.", "evidence": "Document the source case, contextual differences and a local test of the load-bearing assumption.", "falsifier": "A failed local gate or materially different authority structure invalidates direct transfer.", "limits": "Analogies generate hypotheses, not evidence that an outcome will repeat." }, { "@id": "urn:business-engineer:source-entry:pack:246", "@type": "SourceEntry", "id": "pack:246", "sourceNumber": 246, "name": "Organization Design Is Moat Design", "body": "The moat rebuilt on four stones: the residue, the property line, coordination capital, and default status with machine buyers. Cost, then speed with coherence, then optionality, then moat, in strict order. The order matters because each purchase is the entry fee for the next.\n- **Key Q**: \"Which of the four stones is this organization laying, and in what order is it buying cost, speed, optionality, and moat?\"", "sha256": "d6c2f12abcf807f9e20ee40c6e2099ddb0f005aa3ac1bfb93561498685268d67", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0249", "normalizedDefinition": "Residue, a deliberate ownership boundary, coordination capital and default status with machine buyers are four proposed sources of organizational advantage that may reinforce one another.", "evidence": "Measure usable learning, exercised control and exit, coordinated throughput, buyer selection and the difficulty of replicating their combination.", "falsifier": "Easy replication, unused residue, expensive control or no buyer preference weakens the moat claim.", "limits": "The proposed cost-to-speed-to-optionality-to-moat sequence is not a strict law; verify the links and account for complexity and maintenance." }, { "@id": "urn:business-engineer:source-entry:pack:247", "@type": "SourceEntry", "id": "pack:247", "sourceNumber": 247, "name": "The Missing Rung", "body": "AI commoditizes the climb, prices the summit, and removes the stairs. Generation at the bottom rungs becomes symmetric; the premium moves up to judgment and selection; the tool erodes that judgment through sycophancy and removes the apprenticeship that built it. The response is not better judgment but judgment you cannot skip: externalized into a structure that holds at three in the afternoon as at nine.\n- **Key Q**: \"Where in this firm is judgment being built now that the stairs are gone, and is it enforced by structure or by exhortation?\"", "sha256": "b1d6c710305231f7d75a958b4af1414afe20d971a9ac4c1130b1a5944325d546", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0250", "normalizedDefinition": "Automating routine work can remove the practice through which newcomers developed judgment, requiring a deliberate replacement learning path.", "evidence": "Track exposure to cases, feedback quality, error correction and independent competence over time.", "falsifier": "Equivalent skill development through existing paths weakens the claim that the first rung is missing.", "limits": "Ninety days is a configurable program target, not a validated universal time to competence." }, { "@id": "urn:business-engineer:source-entry:pack:248", "@type": "SourceEntry", "id": "pack:248", "sourceNumber": 248, "name": "The Judgment Layer", "body": "Above the loop sits the place only very highly skilled domain experts can stand: the exceptions the suite cannot accept rise to a junction, and the person who decides is the one who can say what the standard should be when the standard is silent. Scarce by construction, it compounds through the seed (spent once, levered forever) and is the firm's defensible position against both the client's agent and the vendor's embedded engineer.\n- **Key Q**: \"Who in this firm can say what the standard should be when it is silent, and does each of their judgments become a case?\"", "sha256": "64637bdf801d02bf7073bad8d83d6810f0f8df5fa48f11ec6b3577424f7d2e8f", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0251", "normalizedDefinition": "Experts can create lasting value by resolving novel exceptions and converting justified decisions into improved standards.", "evidence": "Trace exceptions through adjudication, rationale, standard changes and recurrence reduction.", "falsifier": "Unchanged standards or repeated failures weaken a claim that expert judgment is compounding.", "limits": "Not every exception should become a rule; preserve context and dissent where uncertainty remains." }, { "@id": "urn:business-engineer:source-entry:pack:249", "@type": "SourceEntry", "id": "pack:249", "sourceNumber": 249, "name": "The Seed", "body": "The pyramid was seeded from the bottom; the loop is seeded from the top. A harness is empty until an expert adjudicates the first fifty cases, names the gray areas, and signs the vocabulary. It cannot be done by the machine (it is what is being seeded) or by a junior (who does not know). The expert was the cost the pyramid diluted; in the loop the expert is the seed the leverage grows from.\n- **Key Q**: \"Who seeded this loop, how many cases did they adjudicate, and did they sign the vocabulary?\"", "sha256": "afb0ea97885b4c27d1a544f87aa33e1799ab66c3d41fc38c4740db71c55ba46c", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0252", "normalizedDefinition": "Expert-designed examples and acceptance cases can provide initial structure for a system before operating feedback is available.", "evidence": "Measure coverage, inter-rater agreement, held-out performance and the value of additional cases.", "falsifier": "Poor transfer to fresh cases weakens the seed set's usefulness.", "limits": "A target such as fifty seed cases is illustrative; diversity and difficulty matter more than a fixed count." }, { "@id": "urn:business-engineer:source-entry:pack:250", "@type": "SourceEntry", "id": "pack:250", "sourceNumber": 250, "name": "Leverage Is Loops per Senior", "body": "The professional pyramid's leverage was rate times utilization times leverage in the grinding tier. When the model does the pyramid's work the shape becomes an obelisk, and leverage becomes accepted outcomes the harness lets a senior sign. The pod (senior, builder, operator, harness) replaces the tier; retainer, meter, and share replace the hour; the document was the receipt and the residue is the moat.\n- **Key Q**: \"How many loops does each senior in this firm sign, and is the price attached to the outcome or the hour?\"", "sha256": "77307e75a709246bae3922cff1c51046f2ed7d36a707ffdbbba13ad8314b438f", "sourceCategory": "XXIV. THE ORGANIZATION, THE SEATS, AND THE WORK (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0253", "normalizedDefinition": "An expert can support more valuable work through reusable knowledge and governed execution when review and exception burdens remain manageable.", "evidence": "Compare accepted outcomes, quality, review time, total cost and client value across increasing scope.", "falsifier": "Rising rework or diluted judgment can erase the apparent leverage.", "limits": "Revenue per employee alone omits capital, contractors, pricing and quality." }, { "@id": "urn:business-engineer:source-entry:pack:251", "@type": "SourceEntry", "id": "pack:251", "sourceNumber": 251, "name": "The Four Ownerships", "body": "Regardless of title, the seat handed the AI mandate must own the substrate, the junctions, the standard, and the exit; rent everything else freely, because you can leave. A new title names a gap; it closes it only when it arrives with budget authority, the standard, and the right to stop. Whoever holds the four is the chief AI officer, whatever the card says.\n- **Key Q**: \"Who in this firm holds the substrate, the junctions, the standard, and the exit, before any title is created?\"", "sha256": "bc4146125bef5347273885a84170f6a371c72e5b4f5d2e60675ab3300d984913", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0254", "normalizedDefinition": "Assign accountability for the substrate, the junctions, the acceptance standard and the exit, with budget authority and the right to stop where necessary.", "evidence": "Name the decision right, owner, escalation and supporting artifacts for each ownership.", "falsifier": "Conflicting owners or unowned decisions refute a complete accountability design.", "limits": "These are rights and responsibilities, not four mandatory executive titles." }, { "@id": "urn:business-engineer:source-entry:pack:252", "@type": "SourceEntry", "id": "pack:252", "sourceNumber": 252, "name": "Absorb, Be Displaced, Converge", "body": "When an asset changes character faster than a seat's identity, a new C-title is created and resolves one of three ways: absorbed back into the seat, displacing it, or converging with it. The digital-officer arc was the rhyme; the data-officer arc is the warning. The seat that holds the four absorbs the title; the seat that holds only the door is displaced by it.\n- **Key Q**: \"Is this new title going to be absorbed, displace the seat, or converge with it, and which of the four ownerships decides?\"", "sha256": "1050a29e8059869a520411383b69ae9c2d819abdc4d0234fbc27872dd92a55e2", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0255", "normalizedDefinition": "AI responsibilities can be absorbed by an incumbent role, displace its remit, or converge with another role; a new seat is useful only when the ownership and authority gaps are resolved.", "evidence": "Map the four ownerships and actual authority before comparing title options.", "falsifier": "A new title without resolved authority or capability weakens a reorganization claim.", "limits": "No particular executive title is a universal solution." }, { "@id": "urn:business-engineer:source-entry:pack:253", "@type": "SourceEntry", "id": "pack:253", "sourceNumber": 253, "name": "The Grid (Watch the Blanks)", "body": "Roles sit on a lifecycle across (specify, prepare, build, deploy, evaluate) and five accountable functions down (business owner, domain owner, builder, evaluation owner, adoption owner). Every loop is a path through the grid; an unowned hand-off is an empty cell. Recurring cells are the small center, varying cells the federated edge. A title is evidence of attention, not of a market.\n- **Key Q**: \"Which cells of this firm's grid are blank, and which loop's hand-off is falling through them?\"", "sha256": "f96540596e2de502ccce0d1df3bad4e76a6b51314fbe96c2dc1463fecb2f9b58", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0153", "normalizedDefinition": "Map lifecycle work to accountable functions and specialist contributions, making unowned handoffs and conflicts visible.", "evidence": "Use the source-backed five-stage by five-function grid, then assign one accountable owner to each active handoff.", "falsifier": "Repeated failures at nominally owned handoffs show that titles alone did not create operational coverage.", "limits": "The pack's eleven-column variant is underspecified; the eleven-stage extension is explicitly proposed in this ontology." }, { "@id": "urn:business-engineer:source-entry:pack:254", "@type": "SourceEntry", "id": "pack:254", "sourceNumber": 254, "name": "The Entry Point Moves", "body": "The era is not destroying jobs or creating them; it is moving the entry point from producing the work to owning the loop that produces it. Rebuild the first rung as a ninety-day apprenticeship whose credential is the case study with its failures; convert the analyst tier into operators and evaluators before hiring.\n- **Key Q**: \"Where does a new person enter this firm now, and what is the first rung they stand on?\"", "sha256": "7ef598cee19fbf1e9974ee03d479b17da42ce04b5ae9bce3a4cb45bdbf5cc09c", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0250", "normalizedDefinition": "Redesign junior entry roles around supervised operation, evaluation and learning when routine production tasks are automated.", "evidence": "Assess case-based learning, demonstrated judgment and opportunities to progress beyond tool operation.", "falsifier": "Strong existing apprenticeship outcomes weaken the need to replace the entry path.", "limits": "Automation can both remove and create jobs; no universal employment direction follows." }, { "@id": "urn:business-engineer:source-entry:pack:255", "@type": "SourceEntry", "id": "pack:255", "sourceNumber": 255, "name": "The Seat That Grades Never Built", "body": "The evaluation owner is separated from the builder by design, at the loop and at the top row: the seat that owns the standard is never the seat that builds the loops. Governance reports outside the technology organization. Flatter in function, denser in ownership: a seat is added and a boundary is lost at the same time.\n- **Key Q**: \"In this firm, does the seat that grades the loop ever build it?\"", "sha256": "add4e3f08a6d5b1a007087a5c75440975a12318d78e2698b0cbe24f98d3a8e0a", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0149", "normalizedDefinition": "Separate acceptance authority from delivery incentives sufficiently to make failures visible and actionable.", "evidence": "Inspect reporting lines, veto rights, conflict handling, evaluator access and independent review evidence.", "falsifier": "Overridden findings or builder-controlled acceptance undermine claimed independence.", "limits": "Independence does not require one universal org chart or prohibit all evaluators from ever building systems." }, { "@id": "urn:business-engineer:source-entry:pack:256", "@type": "SourceEntry", "id": "pack:256", "sourceNumber": 256, "name": "The CTO of Someone Else's Company (DEPLOY)", "body": "The deployment seat is accountable for production value while holding no levers. Its sequence is DEPLOY: Discovery · Envelope · Proof · Landing · Outcome · Yield, and every letter has a date. Say no in writing and keep the refusal log; the baseline is taken before, the gauge page after; what comes back is the reference architecture and the product requirement.\n- **Key Q**: \"Which letter of DEPLOY is this engagement on, what is its date, and what did the architect refuse in writing?\"", "sha256": "6f0d6379684e7d9ed62ee0ac459aea3ab9a4ad69d36dc3e707c402e98ce539a1", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0256", "normalizedDefinition": "Move an engagement through Discovery, Envelope, Proof, Landing, Outcome and Yield with dated decisions, evidence and accountable owners.", "evidence": "Track entry evidence, acceptance, constraints, refusal reasons and transition dates for each stage.", "falsifier": "Missing baselines or unsigned operating responsibility refute a claimed completed deployment.", "limits": "The source's four discovery gates and seven-layer shape need explicit local definitions; model feasibility should be tested early." }, { "@id": "urn:business-engineer:source-entry:pack:257", "@type": "SourceEntry", "id": "pack:257", "sourceNumber": 257, "name": "The Railroad Rhyme (Capital Ahead of Demand)", "body": "The right historical rhyme for a physical buildout is the railroad: four panics, one continuous buildout, mileage tripling through them. Not the web bubble. The pattern repeats in the fiber overbuild: capital on a physical clock against demand on its own schedule, the income statement asked first, survivors buying the assets. Real, historic, and, for most of the capital, insufficient.\n- **Key Q**: \"Which rhyme am I using, and does it account for the buildout continuing through the panics?\"", "sha256": "9886e6872ff4833126ae85813f63134cfc83e1a720383630b9d1d5fd86059478", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0093", "normalizedDefinition": "Historical buildouts can produce useful infrastructure while some investors lose money because funding, construction and demand develop at different speeds.", "evidence": "Verify each historical chronology, asset reuse, investment loss and demand path before borrowing the analogy.", "falsifier": "A case with different financing or asset economics weakens a direct historical comparison.", "limits": "Railways and fiber are examples, not exclusive correct analogies; exact panic and mileage claims need independent verification." }, { "@id": "urn:business-engineer:source-entry:pack:258", "@type": "SourceEntry", "id": "pack:258", "sourceNumber": 258, "name": "The Access Rent", "body": "The firm that owns access earns a rent only while access is scarce; when the constraint opens, the rent moves to whatever the input was gating. The dial-up subscription was the first web rent; each era since has repriced the same lesson.\n- **Key Q**: \"Which scarce access is this rent built on, and what happens to the rent when that access opens?\"", "sha256": "57785a7ca5f257ea6c6363e66f0f13aa672b56682b1250136901c1a6ddc2d992", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0129", "normalizedDefinition": "A rent based on scarce access can weaken or migrate when the constraint opens or an alternative route becomes viable.", "evidence": "Track access scarcity, switching options and retained margins after capacity or access changes.", "falsifier": "Sustained differentiated value can preserve rent after the original scarcity ends.", "limits": "Scarcity removal does not determine where all value will move." }, { "@id": "urn:business-engineer:source-entry:pack:259", "@type": "SourceEntry", "id": "pack:259", "sourceNumber": 259, "name": "Get Big Fast, Monetize Later vs Paid From Day One", "body": "The web's growth doctrine assumed a free user with zero marginal cost and an advertiser who would pay later. The AI era's free user is a cost, so the wedge is paid, the metric is the outcome, and the enterprise pays first. Do not import the web's growth math into a business with a cost of goods.\n- **Key Q**: \"Is this growth plan assuming a free user who is an asset, when the free user is now a cost?\"", "sha256": "172eb45e5c042429fb626fc9ebeca5f9cab13f2caf1d3d0a4a21f6d57c14467f", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0204", "normalizedDefinition": "Choose free, paid or mixed entry by comparing customer acquisition and learning benefits with actual servicing cost and conversion.", "evidence": "Model cohort contribution, capacity use, willingness to pay and alternative acquisition paths.", "falsifier": "Profitable free cohorts undermine a claim that every AI wedge must charge immediately.", "limits": "Neither web distribution nor AI delivery has a universal marginal-cost law." }, { "@id": "urn:business-engineer:source-entry:pack:260", "@type": "SourceEntry", "id": "pack:260", "sourceNumber": 260, "name": "Intent Is the Scarcest Thing on the Web", "body": "The auction priced intent in real time and built the most profitable machine ever made from a copy that cost nothing, teaching two decades of finance that software's margin was a law of nature rather than a property of one product. The copy was free for thirty years; that was the accident, not the rule.\n- **Key Q**: \"Which of this business's margin assumptions rests on the copy being free, and does the copy still cost nothing?\"", "sha256": "71057910759fd0618d619b62e0fbe4629b272ed26c13b45f77f88728e322d93e", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0257", "normalizedDefinition": "A service can monetize information about a user's likely purchase or action when it improves matching, conversion or transaction value.", "evidence": "Measure incremental conversion, auction or pricing economics, privacy constraints and substitution.", "falsifier": "Low incremental value or cheaper equivalent matching weakens the intent-rent thesis.", "limits": "Intent is one scarce input among others; avoid universal profitability or zero-copy-cost claims." }, { "@id": "urn:business-engineer:source-entry:pack:261", "@type": "SourceEntry", "id": "pack:261", "sourceNumber": 261, "name": "Web Squared (Outside-In and Inside-Out)", "body": "AI does not replace the web; it compounds it, riding thirty years of the web's infrastructure, data, and distribution, which is why web-native industries transform first. The web changed distribution first and the operating model last (outside-in); AI changes the operating model first, the business model next, and distribution last (inside-out). Organizational transformation is the prerequisite for business-model transformation, which is why enterprise AI is hard. Carry the inside-out nuance only where it serves the argument; drop the branding where it does not.\n- **Key Q**: \"Is this transformation being attempted from the outside in, when the era runs from the inside out?\"", "sha256": "b7eeb707ad719e7225f12631ac1b8388774d17acf311ad9a535f7905eabe277c", "sourceCategory": "XXV. THE SEATS, THE ROLES, AND THE HISTORICAL RHYMES (Compressed)", "sourceDocument": "urn:business-engineer:source-document:pack", "canonicalModel": "urn:business-engineer:model:0258", "normalizedDefinition": "Technology can change distribution, operations and the business model in different sequences depending on existing infrastructure and incentives.", "evidence": "Date changes in workflows, economics and distribution, then compare plausible alternative sequences.", "falsifier": "Distribution-led AI change or operations-led web change refutes a universal era-specific sequence.", "limits": "Outside-in and inside-out are contingent patterns, not historical laws or required branding." }, { "@id": "urn:business-engineer:source-fragment:pack-section-0", "@type": "SourceFragment", "id": "pack-section-0", "name": "0. WHAT THIS PACK DOES", "body": "## 0. WHAT THIS PACK DOES\n\nThe 136-model edition captured the capital-cycle season up to the credit node. Since then the corpus grew in four directions that the skill does not yet encode: the top of the stack (incidence, substitution, the interface concession), the intelligence stack itself (routing, harness, context, the absorption line), the disciplines (engineering, product, growth, economics, valuation), and the firm (organization, seats, roles, the expert). The pack adds 125 models in nine categories, six operational modes, seven instruments, and one corrected visual standard.\n\nDesign rules kept from the 136 edition: cycle-agnostic phrasing, one Key Q per model, compressed register for everything after Model 110, and the counting/epistemic discipline of Phase 4G applied to every entry.\n\n---", "sha256": "1b101179dc8333db06836f00d842d2ae9ca60d62fc0ff0fc68617a085b818ce0", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-1", "@type": "SourceFragment", "id": "pack-section-1", "name": "1. PATCH LIST — what to change in the existing file", "body": "## 1. PATCH LIST — what to change in the existing file\n\n| Location | Change | Why |\n|---|---|---|\n| Phase 4A, anatomy step 1 | Demote \"Price Is Not Standing\" from the opener to a lens used at most once, late. A print leads with the frame and the verdict. | Stock price is not the analytical object. The instrument set (positioning / macro / capital structure / asset returns) stays, as a lens. |\n| Phase 4A, anatomy | Add step 0: \"Name the seat\" (builder / bystander / distributor / control group / supplier / funder / integrator / value-capture pole / rail / taxed). | The Incidence Taxonomy grew from four seats to ten (see Category XVIII). |\n| Phase 4A, verdict verbs | Extend the title-verb set: Absorbed · Paid for · Overshot · Skipped · Reached · Escaped · Priced · Funded · Bought · Financed · Conceded · Collected · Swallowed. One verb per node, never reused in a season. | Each verb names a different position on the clock. |\n| Phase 4C, Acid Test limits | Add two stated limits: (4) trade-credit float at the integration node is invisible to all six gauges; (5) the instrument has no supply-side column, so a supplier that finances its own customers is scored only through G5. | Found in practice on the integrator and supplier prints. |\n| Phase 4D, the hurdle | Replace \"three independent methods converge\" with: external estimates agree by vintage, not by independence; re-running the best-known external method at current supplier run-rate moves the hurdle up. State the counting asymmetry (capital counted across the whole build, revenue only where it transacts) and its two honest repairs. | A reader found the convergence claim was weaker than stated. Own it. |\n| Phase 4D, compounding | Revenue must roughly triple over three years when PP&E purchases run ~3× recognized depreciation; that is ~44%/yr, not 37–40%. State the method inline. | Arithmetic correction. |\n| Phase 4F, the clocks | Add the FIFTH CLOCK: political / return-insensitive state demand. Split the hurdle into a hurdle for return-seeking capital plus a floor set by capital that never had to clear. | Category XVII, Model 139. |\n| Visual Style section | Supersede the card/palette spec with Register II (Editorial Ink) for any plate that sits above a heading; keep the card register only when the artifact IS the data. | The card spec is stale against the registered house style. See Section 5. |\n| Phase 3B, animations | Keep. Add: drawn-mechanism plates (Register II) are the default for essays; animation is for social export only. | Prevents re-deriving the rejected box register. |\n\n---", "sha256": "0028b65616758fd891c15643f8efad14162bed6d5c989632fe36e4bc905908af", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-3", "@type": "SourceFragment", "id": "pack-section-3", "name": "3. OPERATIONAL MODES — ADDITIONS (splice into the Operational Modes table)", "body": "## 3. OPERATIONAL MODES — ADDITIONS (splice into the Operational Modes table)\n\n| Mode | Trigger Keywords | Primary Focus |\n|------|-----------------|---------------|\n| **Valuation** | \"what is it worth\", \"valuation\", \"multiple\", \"run-rate\", \"residual\", \"priced\" | The nine questions in order, the multiple last and only on the residual — Phase 4I |\n| **Buyer Qualification** | \"should we buy\", \"vendor\", \"RFP\", \"pilot\", \"renewal\", \"lock-in\", \"VERIFIED\" | VERIFIED board, procurement-theater screen, priced exit — Phase 4J |\n| **Deployment Decision** | \"deploy\", \"rollout\", \"proof of value\", \"MVP\", \"landing\", \"DEPLOY\" | The six decisions, every letter with a date — Phase 4K |\n| **Organization Climb** | \"our people are faster\", \"AI transformation\", \"reorg\", \"ratio\", \"headcount\", \"governance\" | Neutral-gain diagnosis, the four scales, the governed middle, the six gauges — Phase 4L |\n| **Roles & Grid** | \"hire\", \"team\", \"roles\", \"who owns\", \"org chart\", \"chief AI officer\" | The 11×5 grid, the four ownerships, the ladder, the import test — Phase 4L |\n| **Junction & Geopolitics** | \"geopolitics\", \"export controls\", \"sovereign\", \"chokepoint\", \"standard\", \"gauge\" | Sited / standardised / chokeable, the five clocks, the fence and the tunnel, the cascade — Phase 4M |", "sha256": "c3a0b515f1776cd319bb42cabbfa5a25b854c49f46be477181b9f1077e168cfe", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-4", "@type": "SourceFragment", "id": "pack-section-4", "name": "4. FRAMEWORK SELECTION GUIDE — ADDITIONS (splice into Layer 2 table)", "body": "## 4. FRAMEWORK SELECTION GUIDE — ADDITIONS (splice into Layer 2 table)\n\n| Question Type | Likely Best Frameworks |\n|---------------|----------------------|\n| Which seat is this print in? | Name the Seat (#154), Absorption Capacity (#114), Incidence Runs Opposite (#166) |\n| Is this earnings number real? | Read the Sign of the Distortion (#228), The Related-Party Triple (#160), The Definition Moved (#181) |\n| What is this company worth? | The Multiple Comes Last (#220), The Residual (#222), Hidden Piers (#223), Worthless Cases (#224) |\n| Where does the AI bill land here? | Software Acquires a Cost of Goods (#174), Discovery Tax (#175), Transmission Belt (#149) |\n| Who owns the junction in this stack? | Harness Is a Router (#190), Owned/Rented Barbell (#192), Second Index (#204), Only Door (#205) |\n| Will the next release absorb this product? | Absorption Line (#198), Co-Adaptation (#193), Exhaust Flywheel (#194) |\n| Should we buy this, and on what terms? | The Asymmetry (#229), VERIFIED (#230), Procurement Theater (#231), Clear Title (#136) |\n| Why is our AI gain not showing in margin? | Neutral Gain (#239), Ascent Through Scales (#240), Governed Middle (#241), Ratio Rule (#244) |\n| Who should own AI in this firm? | Four Ownerships (#251), Absorb/Displace/Converge (#252), The Grid (#253), Seat That Grades (#255) |\n| Why did this technology become political? | Junction Rule (#141), Independence Swap (#142), Permission Layer (#143), Cascade Is the Rotation (#140) |\n| Is this a bubble? | Node-by-Node Correction (#137), Two Species (#138), Amplifier Not Bubble (#122), Fifth Clock (#139) |\n\n---", "sha256": "1422c10a4c06373077195bf12383c8f36b05891240ddc7854a6ed6e99d07d983", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-5", "@type": "SourceFragment", "id": "pack-section-5", "name": "5. PHASE 4 — NEW INSTRUMENTS (splice after Phase 4H)", "body": "## 5. PHASE 4 — NEW INSTRUMENTS (splice after Phase 4H)\n\n### I. The Valuation Toolbox (nine questions, the multiple last)\nAsk in order: (1) what are you counting (the counted top line, Model 221); (2) what does it cost to produce (cost per accepted outcome, levers pulled versus available, the ceiling is not the average); (3) what compounds (residue, substrate, standard, owned model, junctions; rarely what the company sells); (4) owned versus rented (title; the exit priced both ways); (5) what is perishable (the absorption line → the residual); (6) whose money (two engines in both directions; trace every line to its payer; the circle); (7) what capital (builders: the three tests and the hurdle; financed builds: the acid test; labs: revenue per megawatt; apps: the margin path; EV equals equity plus debt plus what the balance sheet hides); (8) what kills it (three worthless cases with triggers); (9) the multiple on the residual, borrowed by layer, reconciled to the reported number by naming the question that made the gap.\n**Instruments with formulas**: counted top line (tier → strip → exclude → gross-to-net → run-rate-to-year); margin path (measured, levers, trajectory with dates and capital, tail modelled separately); residual-adjusted cash flow (durable share grows with the compounding assets, perishable share decays per release, terminal value on the durable share only, discount rate by layer); circle-adjusted revenue (payer classes: own budget, partner credits, pilot allowance, the circle); EV bridge with hidden piers; probability-weighted worthless cases; layer multiple table.\n**Meters**: counted-to-reported ratio · measured margin plus lever count · residual fraction · circle share · hidden-obligation multiple · reconciliation gap. **Grading**: V0–V5, where a maturity claimed with a gross run-rate in the headline is V0. **Hard rule**: the hostile reading is written first (Model 227), and every output states that it is analysis, not investment advice.\n\n### J. VERIFIED (the buyer's qualification)\nEight letters, every letter an artifact: Verification owned (the frozen suite is the buyer's) · Economics read (the vendor's margin predicts its behaviour) · Rights scheduled (title on what compounds, in the contract) · Incentives separated (the champion is not the auditor) · Feasibility on your floor (the proof ran on the buyer's data and systems) · Independence priced (exit in engineer-months, rehearsed yearly) · Exposure governed (the behaviour-change audit beside the security review) · Drift instrumented (the drift log has an owner and a cadence). Run V·E·I before contact, F·R·E at the wedge's clock, I·D before signature, then annually. A failed letter does not block the purchase; it prices it. What VERIFIED refuses is the letter nobody checked.\n**The theater screen** (Model 231) runs before the board: which parts of the evaluation could the vendor have staged. **The outcome-pricing stance**: outcome pricing is an end state; underwrite the hybrid and choose the ramp (Model 215).\n\n### K. DEPLOY (the deployment decision sequence)\nDiscovery (four gates, the outcome in the customer's units, saying no in writing) · Envelope (the seven-layer shape, the data path, the autonomy tier and its junction, buy/build/rent, the model chosen last) · Proof (the MVP as contract, evaluations as acceptance, guardrails, approval, rollback) · Landing (the concurrent gauntlet, reviews volunteered, VERIFIED read from the vendor's side) · Outcome (baseline before, gauge page after, a return the finance seat accepts) · Yield (the harvest: reference architecture, product requirement, the refusal log). Grading rule: every letter has a date. Three rooms, one truth at three altitudes: engineers, the CTO and CISO, the executives. Run a book of business, never a single account, and track letters per account.\n\n### L. The Climb (organization, seats, roles)\n**Engine**: Stages 0–5 across four scales. Prime diagnostic: \"Your people are faster. Is the firm ahead?\" **Hard thresholds**: no ratio without a measured gate; residue capture at or above 90%; paved-road coverage including a shadow estimate; conversion time under ninety days; no naked revenue per employee; same-dated ratios; the import test is mandatory. **Six gauges**: loop share, adjudication ratio, residue capture, paved-road coverage, conversion time, aim traceability; headcount is excluded. **The memo rule**: a memo before the paved road is a walk-back waiting to happen. **The grid** (11 functions across, 5 accountable functions down) is the staffing instrument; the top row must hold the four ownerships regardless of titles; the seat that owns the standard never builds the loops. **The first rung**: a ninety-day apprenticeship whose credential is the case study with its failures. **Grading**: O0–O5 and W0–W5, where a stage claimed with a headcount number or a pilot count on the board page is one stage lower than claimed.\n\n### M. The Junction Read (techno-geopolitics)\nFor any technology or buildout: (1) run the three tests, sited / standardised / chokeable; (2) find the junction, the intersecting technologies that turn an industry into a map; (3) locate the permission layer, who can revoke; (4) run the five clocks, adding the political one; (5) name the independence swap the adoption is making and when the dependency invoices; (6) read the fence at its thinnest point; (7) ask which power form the junction favours and what it does to war; (8) price the domestic bill and the institution that will be created to settle it; (9) state the three-generation lag and the falsification tests. Structure the piece as a cross-section: physical base → techno-industrial system → power system, with capital, institutions, and permissions as cross-cutting layers, not stages.\n\n### N. The Thread — Shared Instruments Across the Library\nThe instruments are the framework; each discipline uses them, none replaces them. Reuse by name, never re-derive: the SUITE (the frozen referee) · the CHARTER (one page: outcome, standard, thresholds, surfaces, boundaries, tier, owner) · the GAUGE PAGE (the retention and renewal instrument) · the TWO SURFACES (human and agent) · the JUNCTION (where a private rule is encoded and enforced) · the RESIDUE (the decision loop's second output) · the PROPERTY LINE (own the junctions, rent the ends) · the DRIFT CHECK (re-scored on every release) · the ABSORPTION LINE (perishable versus durable) · the COUNTING RULE (each dollar once, at the tier it transacted) · the CIRCLE (supplier money returning as customer revenue) · the SEAT (the ten seats on the clock). Every long-form deliverable closes with a Thread section mapping the instruments used to where each is treated in full.\n\n### O. Register II — Editorial Ink (supersedes the card/palette spec for essay plates)\n**Selection rule**: if the plate sits above a heading in a written piece, use Register II; use the card register (Register I) only when the artifact IS the data (dashboards, scorecards, decks).\n**Spec**: canvas 1240×900, pure white ground, palette ink #17171B / teal #0D6E6B / teal-2 #12908C / vermilion #C4342A / ochre #D19A2E / muted #7A756C / faint #D9D2C4; Georgia display, Inter kickers, mono ticks. Grid: kicker y=76, title y=134 (44px, carrying the section heading verbatim), subtitle y=178, rule y=202, drawing zone y=210–790, compression rule 810 / line 840, footer 876.\n**Non-negotiables**: no boxes as containers (a box may be a drawn object, never a wrapper); one plate is one conceptual drawing, nameable in five words; every stroke rendered twice with slight bow and jitter; drawn glyphs only (rasterizers drop font arrows and checkmarks); full canvas, never banner strips; hatching and washes instead of flat fills; house furniture on every plate (teal top rule and masthead, title and italic dek, hero mechanism, labelled supporting detail, compression block with red left bar, two numbered questions, italic takeaway over the footer rule); no dates on plates; filenames as descriptive slugs numbered in paragraph order; every argument section gets a plate.\n**Metaphor vocabulary**: valves on a pipe (moving constraint) · screw clamp (binding constraint) · pendulums of different lengths (different clocks) · geological strata (layer stack) · buckets in rain, one under an umbrella (differing absorption) · roots versus canopy (long-lived versus short-lived assets) · two figures carrying a slab (concentrated obligation) · slicer fanning tranches (securitisation) · castle and moat with birds flying over (uncopyable input) · meshed gears of two sizes (supply in years, demand in quarters) · gauge wired to a piggy bank · locomotive crossing trestled chasms (buildout through panics) · balance with hatched pans · a sieve with question-rows (valuation) · a lever with a pyramid on the long arm (consulting leverage) · a lens aperture between strata and a graph (the only door) · four gates in series (the window's defenses) · a staircase with a missing rung.\n**Verification**: run the collision checker (text-vs-text with per-glyph advance widths, text-vs-shape, clip bounds, drawing zone bounds with the art wrapped in its own group) plus a full-resolution render of the hero and any dense plate, plus a contact sheet. If a drawn object is unreadable, swap the metaphor rather than adding a label. When preview is unavailable, say verification was programmatic only. Generate repetitive plate families from one template.\n\n---", "sha256": "f23fd637202d8536a7c95cf5f675448abd0bdb7fcf55f1f04de5713f769c30d8", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-6", "@type": "SourceFragment", "id": "pack-section-6", "name": "6. QUALITY CHECKLIST — ADDITIONS (splice into Phase 3E)", "body": "## 6. QUALITY CHECKLIST — ADDITIONS (splice into Phase 3E)\n\n### Analytical Rigor\n- [ ] Seat named before any test is run (#154)\n- [ ] Marks stripped in both directions (#228); the circle traced (#160)\n- [ ] The hostile reading written before the base case (#227)\n- [ ] The worthless case named with its trigger (#224)\n- [ ] The absorption line drawn: perishable versus durable (#198)\n- [ ] Every ratio checked for stock-over-flow; every point estimate carries a range; the counting asymmetry stated where capital and revenue are counted on different bases\n- [ ] The import test run on any borrowed case (#245)\n\n### Writing Register (applies to every editorial output)\n- [ ] Plain sentences, mostly one idea each; anything over ~40 words split; measure it, do not assert it\n- [ ] No fragment-lists posing as paragraphs; bold budget ~10–12 load-bearing claims; em-dashes rationed, never stacked three deep\n- [ ] Terms earned before use: the plain idea first, the name after; no jargon fired in sequence\n- [ ] Compression means fewer ideas given room, not all ideas with the connective tissue removed\n- [ ] Self-standing external document: no drafting seams, no references to prior versions or to the conversation\n- [ ] Composite cases labelled as composite in one italic aside; one composite runs as a spine, other vignettes vary by industry\n- [ ] A dated why-now section near the front of any framework piece; the instrument's limitation named inside the piece; a closing \"where this sits\" section framed by the question each companion piece answers\n\n---", "sha256": "a63c66dcf714ac5c7abd254dd3c0468cf192f60ca9d10a7839a2062ae27760b9", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-section-7", "@type": "SourceFragment", "id": "pack-section-7", "name": "7. LIBRARY COUNT (replace every \"136\" in the file)", "body": "## 7. LIBRARY COUNT (replace every \"136\" in the file)\nTotal models after this pack: **261**, across **twenty-five categories**. Update the frontmatter description, the Layer 1 box, the Key Principles line, and the Harness product copy accordingly.\n\n*Analysis by The Business Engineer — by Gennaro Cuofano*", "sha256": "135876397d3a14bb17333ec4b0c8bbb9db7a570531da2983c288cfa86feb3fe2", "sourceDocument": "urn:business-engineer:source-document:pack" }, { "@id": "urn:business-engineer:source-fragment:pack-use", "@type": "SourceFragment", "id": "pack-use", "name": "Pack usage rules", "body": "#### How to Use the Library (replaces the existing block)\n1. Identify the question, then name the SEAT (Model 154) and the LAYER before choosing any model.\n2. Search by category. Categories I–XIII are the general toolkit; XIV–XVIII are the capital cycle; XIX–XX are the stack; XXI–XXII are the disciplines and valuation; XXIII–XXV are the enterprise, the organization, and the rhymes.\n3. Select two or three models that illuminate different angles; at least one should be a test the subject could fail.\n4. Apply the steps; do not skip the counterfactual.\n5. Cross-reference: where else does this pattern appear, and at which altitude (Model 191)?\n6. Synthesize: the convergence or divergence of the models is the finding.", "sourceDocument": "urn:business-engineer:source-document:pack", "sha256": "4ef74a9b3e3d0b9b0685fa23b5307db4167f39b9f65ef44d0ca1596bce28353e" }, { "@id": "urn:business-engineer:mapping:base:1", "@type": "Mapping", "id": "base:1", "sourceEntry": "urn:business-engineer:source-entry:base:1", "targetModel": "urn:business-engineer:model:0001", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:2", "@type": "Mapping", "id": "base:2", "sourceEntry": "urn:business-engineer:source-entry:base:2", "targetModel": "urn:business-engineer:model:0002", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:3", "@type": "Mapping", "id": "base:3", "sourceEntry": "urn:business-engineer:source-entry:base:3", "targetModel": "urn:business-engineer:model:0003", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:4", "@type": "Mapping", "id": "base:4", "sourceEntry": "urn:business-engineer:source-entry:base:4", "targetModel": "urn:business-engineer:model:0004", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:5", "@type": "Mapping", "id": "base:5", "sourceEntry": "urn:business-engineer:source-entry:base:5", "targetModel": "urn:business-engineer:model:0005", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:6", "@type": "Mapping", "id": "base:6", "sourceEntry": "urn:business-engineer:source-entry:base:6", "targetModel": "urn:business-engineer:model:0006", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:7", "@type": "Mapping", "id": "base:7", "sourceEntry": "urn:business-engineer:source-entry:base:7", "targetModel": "urn:business-engineer:model:0007", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:8", "@type": "Mapping", "id": "base:8", "sourceEntry": "urn:business-engineer:source-entry:base:8", "targetModel": "urn:business-engineer:model:0008", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:9", "@type": "Mapping", "id": "base:9", "sourceEntry": "urn:business-engineer:source-entry:base:9", "targetModel": "urn:business-engineer:model:0009", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:10", "@type": "Mapping", "id": "base:10", "sourceEntry": "urn:business-engineer:source-entry:base:10", "targetModel": "urn:business-engineer:model:0010", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:11", "@type": "Mapping", "id": "base:11", "sourceEntry": "urn:business-engineer:source-entry:base:11", "targetModel": "urn:business-engineer:model:0011", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:12", "@type": "Mapping", "id": "base:12", "sourceEntry": "urn:business-engineer:source-entry:base:12", "targetModel": "urn:business-engineer:model:0012", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:13", "@type": "Mapping", "id": "base:13", "sourceEntry": "urn:business-engineer:source-entry:base:13", "targetModel": "urn:business-engineer:model:0013", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:14", "@type": "Mapping", "id": "base:14", "sourceEntry": "urn:business-engineer:source-entry:base:14", "targetModel": "urn:business-engineer:model:0014", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:15", "@type": "Mapping", "id": "base:15", "sourceEntry": "urn:business-engineer:source-entry:base:15", "targetModel": "urn:business-engineer:model:0015", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:16", "@type": "Mapping", "id": "base:16", "sourceEntry": "urn:business-engineer:source-entry:base:16", "targetModel": "urn:business-engineer:model:0016", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:17", "@type": "Mapping", "id": "base:17", "sourceEntry": "urn:business-engineer:source-entry:base:17", "targetModel": "urn:business-engineer:model:0017", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:18", "@type": "Mapping", "id": "base:18", "sourceEntry": "urn:business-engineer:source-entry:base:18", "targetModel": "urn:business-engineer:model:0018", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:19", "@type": "Mapping", "id": "base:19", "sourceEntry": "urn:business-engineer:source-entry:base:19", "targetModel": "urn:business-engineer:model:0019", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:20", "@type": "Mapping", "id": "base:20", "sourceEntry": "urn:business-engineer:source-entry:base:20", "targetModel": "urn:business-engineer:model:0020", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:21", "@type": "Mapping", "id": "base:21", "sourceEntry": "urn:business-engineer:source-entry:base:21", "targetModel": "urn:business-engineer:model:0021", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:22", "@type": "Mapping", "id": "base:22", "sourceEntry": "urn:business-engineer:source-entry:base:22", "targetModel": "urn:business-engineer:model:0022", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:23", "@type": "Mapping", "id": "base:23", "sourceEntry": "urn:business-engineer:source-entry:base:23", "targetModel": "urn:business-engineer:model:0023", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:24", "@type": "Mapping", "id": "base:24", "sourceEntry": "urn:business-engineer:source-entry:base:24", "targetModel": "urn:business-engineer:model:0024", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:25", "@type": "Mapping", "id": "base:25", "sourceEntry": "urn:business-engineer:source-entry:base:25", "targetModel": "urn:business-engineer:model:0025", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:26", "@type": "Mapping", "id": "base:26", "sourceEntry": "urn:business-engineer:source-entry:base:26", "targetModel": "urn:business-engineer:model:0026", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:27", "@type": "Mapping", "id": "base:27", "sourceEntry": "urn:business-engineer:source-entry:base:27", "targetModel": "urn:business-engineer:model:0027", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:28", "@type": "Mapping", "id": "base:28", "sourceEntry": "urn:business-engineer:source-entry:base:28", "targetModel": "urn:business-engineer:model:0028", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:29", "@type": "Mapping", "id": "base:29", "sourceEntry": "urn:business-engineer:source-entry:base:29", "targetModel": "urn:business-engineer:model:0029", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:30", "@type": "Mapping", "id": "base:30", "sourceEntry": "urn:business-engineer:source-entry:base:30", "targetModel": "urn:business-engineer:model:0030", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:31", "@type": "Mapping", "id": "base:31", "sourceEntry": "urn:business-engineer:source-entry:base:31", "targetModel": "urn:business-engineer:model:0031", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:32", "@type": "Mapping", "id": "base:32", "sourceEntry": "urn:business-engineer:source-entry:base:32", "targetModel": "urn:business-engineer:model:0032", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:33", "@type": "Mapping", "id": "base:33", "sourceEntry": "urn:business-engineer:source-entry:base:33", "targetModel": "urn:business-engineer:model:0033", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:34", "@type": "Mapping", "id": "base:34", "sourceEntry": "urn:business-engineer:source-entry:base:34", "targetModel": "urn:business-engineer:model:0034", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:35", "@type": "Mapping", "id": "base:35", "sourceEntry": "urn:business-engineer:source-entry:base:35", "targetModel": "urn:business-engineer:model:0035", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:36", "@type": "Mapping", "id": "base:36", "sourceEntry": "urn:business-engineer:source-entry:base:36", "targetModel": "urn:business-engineer:model:0036", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:37", "@type": "Mapping", "id": "base:37", "sourceEntry": "urn:business-engineer:source-entry:base:37", "targetModel": "urn:business-engineer:model:0037", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:38", "@type": "Mapping", "id": "base:38", "sourceEntry": "urn:business-engineer:source-entry:base:38", "targetModel": "urn:business-engineer:model:0038", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:39", "@type": "Mapping", "id": "base:39", "sourceEntry": "urn:business-engineer:source-entry:base:39", "targetModel": "urn:business-engineer:model:0039", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:40", "@type": "Mapping", "id": "base:40", "sourceEntry": "urn:business-engineer:source-entry:base:40", "targetModel": "urn:business-engineer:model:0040", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:41", "@type": "Mapping", "id": "base:41", "sourceEntry": "urn:business-engineer:source-entry:base:41", "targetModel": "urn:business-engineer:model:0041", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:42", "@type": "Mapping", "id": "base:42", "sourceEntry": "urn:business-engineer:source-entry:base:42", "targetModel": "urn:business-engineer:model:0042", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:43", "@type": "Mapping", "id": "base:43", "sourceEntry": "urn:business-engineer:source-entry:base:43", "targetModel": "urn:business-engineer:model:0043", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:44", "@type": "Mapping", "id": "base:44", "sourceEntry": "urn:business-engineer:source-entry:base:44", "targetModel": "urn:business-engineer:model:0044", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:45", "@type": "Mapping", "id": "base:45", "sourceEntry": "urn:business-engineer:source-entry:base:45", "targetModel": "urn:business-engineer:model:0045", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:46", "@type": "Mapping", "id": "base:46", "sourceEntry": "urn:business-engineer:source-entry:base:46", "targetModel": "urn:business-engineer:model:0046", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:47", "@type": "Mapping", "id": "base:47", "sourceEntry": "urn:business-engineer:source-entry:base:47", "targetModel": "urn:business-engineer:model:0047", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:48", "@type": "Mapping", "id": "base:48", "sourceEntry": "urn:business-engineer:source-entry:base:48", "targetModel": "urn:business-engineer:model:0048", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:49", "@type": "Mapping", "id": "base:49", "sourceEntry": "urn:business-engineer:source-entry:base:49", "targetModel": "urn:business-engineer:model:0049", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:50", "@type": "Mapping", "id": "base:50", "sourceEntry": "urn:business-engineer:source-entry:base:50", "targetModel": "urn:business-engineer:model:0050", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:51", "@type": "Mapping", "id": "base:51", "sourceEntry": "urn:business-engineer:source-entry:base:51", "targetModel": "urn:business-engineer:model:0051", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:52", "@type": "Mapping", "id": "base:52", "sourceEntry": "urn:business-engineer:source-entry:base:52", "targetModel": "urn:business-engineer:model:0052", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:53", "@type": "Mapping", "id": "base:53", "sourceEntry": "urn:business-engineer:source-entry:base:53", "targetModel": "urn:business-engineer:model:0053", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:54", "@type": "Mapping", "id": "base:54", "sourceEntry": "urn:business-engineer:source-entry:base:54", "targetModel": "urn:business-engineer:model:0054", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:55", "@type": "Mapping", "id": "base:55", "sourceEntry": "urn:business-engineer:source-entry:base:55", "targetModel": "urn:business-engineer:model:0055", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:56", "@type": "Mapping", "id": "base:56", "sourceEntry": "urn:business-engineer:source-entry:base:56", "targetModel": "urn:business-engineer:model:0056", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:57", "@type": "Mapping", "id": "base:57", "sourceEntry": "urn:business-engineer:source-entry:base:57", "targetModel": "urn:business-engineer:model:0057", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:58", "@type": "Mapping", "id": "base:58", "sourceEntry": "urn:business-engineer:source-entry:base:58", "targetModel": "urn:business-engineer:model:0058", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:59", "@type": "Mapping", "id": "base:59", "sourceEntry": "urn:business-engineer:source-entry:base:59", "targetModel": "urn:business-engineer:model:0059", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:60", "@type": "Mapping", "id": "base:60", "sourceEntry": "urn:business-engineer:source-entry:base:60", "targetModel": "urn:business-engineer:model:0060", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:61", "@type": "Mapping", "id": "base:61", "sourceEntry": "urn:business-engineer:source-entry:base:61", "targetModel": "urn:business-engineer:model:0061", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:62", "@type": "Mapping", "id": "base:62", "sourceEntry": "urn:business-engineer:source-entry:base:62", "targetModel": "urn:business-engineer:model:0062", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:63", "@type": "Mapping", "id": "base:63", "sourceEntry": "urn:business-engineer:source-entry:base:63", "targetModel": "urn:business-engineer:model:0063", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:64", "@type": "Mapping", "id": "base:64", "sourceEntry": "urn:business-engineer:source-entry:base:64", "targetModel": "urn:business-engineer:model:0064", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:65", "@type": "Mapping", "id": "base:65", "sourceEntry": "urn:business-engineer:source-entry:base:65", "targetModel": "urn:business-engineer:model:0065", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:66", "@type": "Mapping", "id": "base:66", "sourceEntry": "urn:business-engineer:source-entry:base:66", "targetModel": "urn:business-engineer:model:0066", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:67", "@type": "Mapping", "id": "base:67", "sourceEntry": "urn:business-engineer:source-entry:base:67", "targetModel": "urn:business-engineer:model:0067", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:68", "@type": "Mapping", "id": "base:68", "sourceEntry": "urn:business-engineer:source-entry:base:68", "targetModel": "urn:business-engineer:model:0068", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:69", "@type": "Mapping", "id": "base:69", "sourceEntry": "urn:business-engineer:source-entry:base:69", "targetModel": "urn:business-engineer:model:0069", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:70", "@type": "Mapping", "id": "base:70", "sourceEntry": "urn:business-engineer:source-entry:base:70", "targetModel": "urn:business-engineer:model:0047", "mappingKind": "legacyAlias", "definition": "The earlier library already identifies this as a duplicate alias; its number is preserved and not reused." }, { "@id": "urn:business-engineer:mapping:base:71", "@type": "Mapping", "id": "base:71", "sourceEntry": "urn:business-engineer:source-entry:base:71", "targetModel": "urn:business-engineer:model:0071", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:72", "@type": "Mapping", "id": "base:72", "sourceEntry": "urn:business-engineer:source-entry:base:72", "targetModel": "urn:business-engineer:model:0072", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:73", "@type": "Mapping", "id": "base:73", "sourceEntry": "urn:business-engineer:source-entry:base:73", "targetModel": "urn:business-engineer:model:0073", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:74", "@type": "Mapping", "id": "base:74", "sourceEntry": "urn:business-engineer:source-entry:base:74", "targetModel": "urn:business-engineer:model:0037", "mappingKind": "legacyAlias", "definition": "The earlier library already identifies this as a duplicate alias; its number is preserved and not reused." }, { "@id": "urn:business-engineer:mapping:base:75", "@type": "Mapping", "id": "base:75", "sourceEntry": "urn:business-engineer:source-entry:base:75", "targetModel": "urn:business-engineer:model:0075", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:76", "@type": "Mapping", "id": "base:76", "sourceEntry": "urn:business-engineer:source-entry:base:76", "targetModel": "urn:business-engineer:model:0076", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:77", "@type": "Mapping", "id": "base:77", "sourceEntry": "urn:business-engineer:source-entry:base:77", "targetModel": "urn:business-engineer:model:0077", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:78", "@type": "Mapping", "id": "base:78", "sourceEntry": "urn:business-engineer:source-entry:base:78", "targetModel": "urn:business-engineer:model:0078", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:79", "@type": "Mapping", "id": "base:79", "sourceEntry": "urn:business-engineer:source-entry:base:79", "targetModel": "urn:business-engineer:model:0079", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:80", "@type": "Mapping", "id": "base:80", "sourceEntry": "urn:business-engineer:source-entry:base:80", "targetModel": "urn:business-engineer:model:0080", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:81", "@type": "Mapping", "id": "base:81", "sourceEntry": "urn:business-engineer:source-entry:base:81", "targetModel": "urn:business-engineer:model:0081", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:82", "@type": "Mapping", "id": "base:82", "sourceEntry": "urn:business-engineer:source-entry:base:82", "targetModel": "urn:business-engineer:model:0082", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:83", "@type": "Mapping", "id": "base:83", "sourceEntry": "urn:business-engineer:source-entry:base:83", "targetModel": "urn:business-engineer:model:0083", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:84", "@type": "Mapping", "id": "base:84", "sourceEntry": "urn:business-engineer:source-entry:base:84", "targetModel": "urn:business-engineer:model:0084", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:85", "@type": "Mapping", "id": "base:85", "sourceEntry": "urn:business-engineer:source-entry:base:85", "targetModel": "urn:business-engineer:model:0085", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:86", "@type": "Mapping", "id": "base:86", "sourceEntry": "urn:business-engineer:source-entry:base:86", "targetModel": "urn:business-engineer:model:0086", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:87", "@type": "Mapping", "id": "base:87", "sourceEntry": "urn:business-engineer:source-entry:base:87", "targetModel": "urn:business-engineer:model:0087", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:88", "@type": "Mapping", "id": "base:88", "sourceEntry": "urn:business-engineer:source-entry:base:88", "targetModel": "urn:business-engineer:model:0088", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:89", "@type": "Mapping", "id": "base:89", "sourceEntry": "urn:business-engineer:source-entry:base:89", "targetModel": "urn:business-engineer:model:0089", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:90", "@type": "Mapping", "id": "base:90", "sourceEntry": "urn:business-engineer:source-entry:base:90", "targetModel": "urn:business-engineer:model:0090", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:91", "@type": "Mapping", "id": "base:91", "sourceEntry": "urn:business-engineer:source-entry:base:91", "targetModel": "urn:business-engineer:model:0091", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:92", "@type": "Mapping", "id": "base:92", "sourceEntry": "urn:business-engineer:source-entry:base:92", "targetModel": "urn:business-engineer:model:0092", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:93", "@type": "Mapping", "id": "base:93", "sourceEntry": "urn:business-engineer:source-entry:base:93", "targetModel": "urn:business-engineer:model:0093", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:94", "@type": "Mapping", "id": "base:94", "sourceEntry": "urn:business-engineer:source-entry:base:94", "targetModel": "urn:business-engineer:model:0094", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:95", "@type": "Mapping", "id": "base:95", "sourceEntry": "urn:business-engineer:source-entry:base:95", "targetModel": "urn:business-engineer:model:0095", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:96", "@type": "Mapping", "id": "base:96", "sourceEntry": "urn:business-engineer:source-entry:base:96", "targetModel": "urn:business-engineer:model:0096", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:97", "@type": "Mapping", "id": "base:97", "sourceEntry": "urn:business-engineer:source-entry:base:97", "targetModel": "urn:business-engineer:model:0097", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:98", "@type": "Mapping", "id": "base:98", "sourceEntry": "urn:business-engineer:source-entry:base:98", "targetModel": "urn:business-engineer:model:0098", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:99", "@type": "Mapping", "id": "base:99", "sourceEntry": "urn:business-engineer:source-entry:base:99", "targetModel": "urn:business-engineer:model:0099", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:100", "@type": "Mapping", "id": "base:100", "sourceEntry": "urn:business-engineer:source-entry:base:100", "targetModel": "urn:business-engineer:model:0100", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:101", "@type": "Mapping", "id": "base:101", "sourceEntry": "urn:business-engineer:source-entry:base:101", "targetModel": "urn:business-engineer:model:0101", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:102", "@type": "Mapping", "id": "base:102", "sourceEntry": "urn:business-engineer:source-entry:base:102", "targetModel": "urn:business-engineer:model:0102", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:103", "@type": "Mapping", "id": "base:103", "sourceEntry": "urn:business-engineer:source-entry:base:103", "targetModel": "urn:business-engineer:model:0103", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:104", "@type": "Mapping", "id": "base:104", "sourceEntry": "urn:business-engineer:source-entry:base:104", "targetModel": "urn:business-engineer:model:0104", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:105", "@type": "Mapping", "id": "base:105", "sourceEntry": "urn:business-engineer:source-entry:base:105", "targetModel": "urn:business-engineer:model:0105", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:106", "@type": "Mapping", "id": "base:106", "sourceEntry": "urn:business-engineer:source-entry:base:106", "targetModel": "urn:business-engineer:model:0106", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:107", "@type": "Mapping", "id": "base:107", "sourceEntry": "urn:business-engineer:source-entry:base:107", "targetModel": "urn:business-engineer:model:0107", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:108", "@type": "Mapping", "id": "base:108", "sourceEntry": "urn:business-engineer:source-entry:base:108", "targetModel": "urn:business-engineer:model:0108", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:109", "@type": "Mapping", "id": "base:109", "sourceEntry": "urn:business-engineer:source-entry:base:109", "targetModel": "urn:business-engineer:model:0109", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:110", "@type": "Mapping", "id": "base:110", "sourceEntry": "urn:business-engineer:source-entry:base:110", "targetModel": "urn:business-engineer:model:0110", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:111", "@type": "Mapping", "id": "base:111", "sourceEntry": "urn:business-engineer:source-entry:base:111", "targetModel": "urn:business-engineer:model:0111", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:112", "@type": "Mapping", "id": "base:112", "sourceEntry": "urn:business-engineer:source-entry:base:112", "targetModel": "urn:business-engineer:model:0112", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:113", "@type": "Mapping", "id": "base:113", "sourceEntry": "urn:business-engineer:source-entry:base:113", "targetModel": "urn:business-engineer:model:0113", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:114", "@type": "Mapping", "id": "base:114", "sourceEntry": "urn:business-engineer:source-entry:base:114", "targetModel": "urn:business-engineer:model:0114", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:115", "@type": "Mapping", "id": "base:115", "sourceEntry": "urn:business-engineer:source-entry:base:115", "targetModel": "urn:business-engineer:model:0115", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:116", "@type": "Mapping", "id": "base:116", "sourceEntry": "urn:business-engineer:source-entry:base:116", "targetModel": "urn:business-engineer:model:0116", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:117", "@type": "Mapping", "id": "base:117", "sourceEntry": "urn:business-engineer:source-entry:base:117", "targetModel": "urn:business-engineer:model:0117", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:118", "@type": "Mapping", "id": "base:118", "sourceEntry": "urn:business-engineer:source-entry:base:118", "targetModel": "urn:business-engineer:model:0118", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:119", "@type": "Mapping", "id": "base:119", "sourceEntry": "urn:business-engineer:source-entry:base:119", "targetModel": "urn:business-engineer:model:0119", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:120", "@type": "Mapping", "id": "base:120", "sourceEntry": "urn:business-engineer:source-entry:base:120", "targetModel": "urn:business-engineer:model:0120", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:121", "@type": "Mapping", "id": "base:121", "sourceEntry": "urn:business-engineer:source-entry:base:121", "targetModel": "urn:business-engineer:model:0121", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:122", "@type": "Mapping", "id": "base:122", "sourceEntry": "urn:business-engineer:source-entry:base:122", "targetModel": "urn:business-engineer:model:0122", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:123", "@type": "Mapping", "id": "base:123", "sourceEntry": "urn:business-engineer:source-entry:base:123", "targetModel": "urn:business-engineer:model:0123", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:124", "@type": "Mapping", "id": "base:124", "sourceEntry": "urn:business-engineer:source-entry:base:124", "targetModel": "urn:business-engineer:model:0124", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:125", "@type": "Mapping", "id": "base:125", "sourceEntry": "urn:business-engineer:source-entry:base:125", "targetModel": "urn:business-engineer:model:0125", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:126", "@type": "Mapping", "id": "base:126", "sourceEntry": "urn:business-engineer:source-entry:base:126", "targetModel": "urn:business-engineer:model:0126", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:127", "@type": "Mapping", "id": "base:127", "sourceEntry": "urn:business-engineer:source-entry:base:127", "targetModel": "urn:business-engineer:model:0127", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:128", "@type": "Mapping", "id": "base:128", "sourceEntry": "urn:business-engineer:source-entry:base:128", "targetModel": "urn:business-engineer:model:0128", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:129", "@type": "Mapping", "id": "base:129", "sourceEntry": "urn:business-engineer:source-entry:base:129", "targetModel": "urn:business-engineer:model:0129", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:130", "@type": "Mapping", "id": "base:130", "sourceEntry": "urn:business-engineer:source-entry:base:130", "targetModel": "urn:business-engineer:model:0130", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:131", "@type": "Mapping", "id": "base:131", "sourceEntry": "urn:business-engineer:source-entry:base:131", "targetModel": "urn:business-engineer:model:0131", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:132", "@type": "Mapping", "id": "base:132", "sourceEntry": "urn:business-engineer:source-entry:base:132", "targetModel": "urn:business-engineer:model:0132", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:133", "@type": "Mapping", "id": "base:133", "sourceEntry": "urn:business-engineer:source-entry:base:133", "targetModel": "urn:business-engineer:model:0133", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:134", "@type": "Mapping", "id": "base:134", "sourceEntry": "urn:business-engineer:source-entry:base:134", "targetModel": "urn:business-engineer:model:0134", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:135", "@type": "Mapping", "id": "base:135", "sourceEntry": "urn:business-engineer:source-entry:base:135", "targetModel": "urn:business-engineer:model:0135", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:base:136", "@type": "Mapping", "id": "base:136", "sourceEntry": "urn:business-engineer:source-entry:base:136", "targetModel": "urn:business-engineer:model:0136", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:137", "@type": "Mapping", "id": "expansion:137", "sourceEntry": "urn:business-engineer:source-entry:expansion:137", "targetModel": "urn:business-engineer:model:0137", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:138", "@type": "Mapping", "id": "expansion:138", "sourceEntry": "urn:business-engineer:source-entry:expansion:138", "targetModel": "urn:business-engineer:model:0138", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:139", "@type": "Mapping", "id": "expansion:139", "sourceEntry": "urn:business-engineer:source-entry:expansion:139", "targetModel": "urn:business-engineer:model:0139", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:140", "@type": "Mapping", "id": "expansion:140", "sourceEntry": "urn:business-engineer:source-entry:expansion:140", "targetModel": "urn:business-engineer:model:0140", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:141", "@type": "Mapping", "id": "expansion:141", "sourceEntry": "urn:business-engineer:source-entry:expansion:141", "targetModel": "urn:business-engineer:model:0141", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:142", "@type": "Mapping", "id": "expansion:142", "sourceEntry": "urn:business-engineer:source-entry:expansion:142", "targetModel": "urn:business-engineer:model:0142", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:143", "@type": "Mapping", "id": "expansion:143", "sourceEntry": "urn:business-engineer:source-entry:expansion:143", "targetModel": "urn:business-engineer:model:0143", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:144", "@type": "Mapping", "id": "expansion:144", "sourceEntry": "urn:business-engineer:source-entry:expansion:144", "targetModel": "urn:business-engineer:model:0144", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:145", "@type": "Mapping", "id": "expansion:145", "sourceEntry": "urn:business-engineer:source-entry:expansion:145", "targetModel": "urn:business-engineer:model:0145", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:146", "@type": "Mapping", "id": "expansion:146", "sourceEntry": "urn:business-engineer:source-entry:expansion:146", "targetModel": "urn:business-engineer:model:0146", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:147", "@type": "Mapping", "id": "expansion:147", "sourceEntry": "urn:business-engineer:source-entry:expansion:147", "targetModel": "urn:business-engineer:model:0147", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:148", "@type": "Mapping", "id": "expansion:148", "sourceEntry": "urn:business-engineer:source-entry:expansion:148", "targetModel": "urn:business-engineer:model:0148", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:149", "@type": "Mapping", "id": "expansion:149", "sourceEntry": "urn:business-engineer:source-entry:expansion:149", "targetModel": "urn:business-engineer:model:0149", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:150", "@type": "Mapping", "id": "expansion:150", "sourceEntry": "urn:business-engineer:source-entry:expansion:150", "targetModel": "urn:business-engineer:model:0150", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:151", "@type": "Mapping", "id": "expansion:151", "sourceEntry": "urn:business-engineer:source-entry:expansion:151", "targetModel": "urn:business-engineer:model:0151", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:152", "@type": "Mapping", "id": "expansion:152", "sourceEntry": "urn:business-engineer:source-entry:expansion:152", "targetModel": "urn:business-engineer:model:0152", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:153", "@type": "Mapping", "id": "expansion:153", "sourceEntry": "urn:business-engineer:source-entry:expansion:153", "targetModel": "urn:business-engineer:model:0153", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:154", "@type": "Mapping", "id": "expansion:154", "sourceEntry": "urn:business-engineer:source-entry:expansion:154", "targetModel": "urn:business-engineer:model:0154", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:155", "@type": "Mapping", "id": "expansion:155", "sourceEntry": "urn:business-engineer:source-entry:expansion:155", "targetModel": "urn:business-engineer:model:0155", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:156", "@type": "Mapping", "id": "expansion:156", "sourceEntry": "urn:business-engineer:source-entry:expansion:156", "targetModel": "urn:business-engineer:model:0156", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:157", "@type": "Mapping", "id": "expansion:157", "sourceEntry": "urn:business-engineer:source-entry:expansion:157", "targetModel": "urn:business-engineer:model:0157", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:158", "@type": "Mapping", "id": "expansion:158", "sourceEntry": "urn:business-engineer:source-entry:expansion:158", "targetModel": "urn:business-engineer:model:0158", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:159", "@type": "Mapping", "id": "expansion:159", "sourceEntry": "urn:business-engineer:source-entry:expansion:159", "targetModel": "urn:business-engineer:model:0159", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:160", "@type": "Mapping", "id": "expansion:160", "sourceEntry": "urn:business-engineer:source-entry:expansion:160", "targetModel": "urn:business-engineer:model:0160", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:161", "@type": "Mapping", "id": "expansion:161", "sourceEntry": "urn:business-engineer:source-entry:expansion:161", "targetModel": "urn:business-engineer:model:0161", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:162", "@type": "Mapping", "id": "expansion:162", "sourceEntry": "urn:business-engineer:source-entry:expansion:162", "targetModel": "urn:business-engineer:model:0162", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:163", "@type": "Mapping", "id": "expansion:163", "sourceEntry": "urn:business-engineer:source-entry:expansion:163", "targetModel": "urn:business-engineer:model:0163", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:164", "@type": "Mapping", "id": "expansion:164", "sourceEntry": "urn:business-engineer:source-entry:expansion:164", "targetModel": "urn:business-engineer:model:0164", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:165", "@type": "Mapping", "id": "expansion:165", "sourceEntry": "urn:business-engineer:source-entry:expansion:165", "targetModel": "urn:business-engineer:model:0165", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:166", "@type": "Mapping", "id": "expansion:166", "sourceEntry": "urn:business-engineer:source-entry:expansion:166", "targetModel": "urn:business-engineer:model:0166", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:167", "@type": "Mapping", "id": "expansion:167", "sourceEntry": "urn:business-engineer:source-entry:expansion:167", "targetModel": "urn:business-engineer:model:0167", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:expansion:168", "@type": "Mapping", "id": "expansion:168", "sourceEntry": "urn:business-engineer:source-entry:expansion:168", "targetModel": "urn:business-engineer:model:0168", "mappingKind": "canonicalization", "definition": "Retains the source mechanism under a stable identity; the current definition and boundaries govern use." }, { "@id": "urn:business-engineer:mapping:pack:137", "@type": "Mapping", "id": "pack:137", "sourceEntry": "urn:business-engineer:source-entry:pack:137", "targetModel": "urn:business-engineer:model:0132", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:138", "@type": "Mapping", "id": "pack:138", "sourceEntry": "urn:business-engineer:source-entry:pack:138", "targetModel": "urn:business-engineer:model:0169", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:139", "@type": "Mapping", "id": "pack:139", "sourceEntry": "urn:business-engineer:source-entry:pack:139", "targetModel": "urn:business-engineer:model:0170", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:140", "@type": "Mapping", "id": "pack:140", "sourceEntry": "urn:business-engineer:source-entry:pack:140", "targetModel": "urn:business-engineer:model:0138", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:141", "@type": "Mapping", "id": "pack:141", "sourceEntry": "urn:business-engineer:source-entry:pack:141", "targetModel": "urn:business-engineer:model:0171", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:142", "@type": "Mapping", "id": "pack:142", "sourceEntry": "urn:business-engineer:source-entry:pack:142", "targetModel": "urn:business-engineer:model:0172", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:143", "@type": "Mapping", "id": "pack:143", "sourceEntry": "urn:business-engineer:source-entry:pack:143", "targetModel": "urn:business-engineer:model:0173", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:144", "@type": "Mapping", "id": "pack:144", "sourceEntry": "urn:business-engineer:source-entry:pack:144", "targetModel": "urn:business-engineer:model:0174", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:145", "@type": "Mapping", "id": "pack:145", "sourceEntry": "urn:business-engineer:source-entry:pack:145", "targetModel": "urn:business-engineer:model:0175", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:146", "@type": "Mapping", "id": "pack:146", "sourceEntry": "urn:business-engineer:source-entry:pack:146", "targetModel": "urn:business-engineer:model:0176", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:147", "@type": "Mapping", "id": "pack:147", "sourceEntry": "urn:business-engineer:source-entry:pack:147", "targetModel": "urn:business-engineer:model:0177", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:148", "@type": "Mapping", "id": "pack:148", "sourceEntry": "urn:business-engineer:source-entry:pack:148", "targetModel": "urn:business-engineer:model:0178", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:149", "@type": "Mapping", "id": "pack:149", "sourceEntry": "urn:business-engineer:source-entry:pack:149", "targetModel": "urn:business-engineer:model:0179", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:150", "@type": "Mapping", "id": "pack:150", "sourceEntry": "urn:business-engineer:source-entry:pack:150", "targetModel": "urn:business-engineer:model:0134", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:151", "@type": "Mapping", "id": "pack:151", "sourceEntry": "urn:business-engineer:source-entry:pack:151", "targetModel": "urn:business-engineer:model:0180", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:152", "@type": "Mapping", "id": "pack:152", "sourceEntry": "urn:business-engineer:source-entry:pack:152", "targetModel": "urn:business-engineer:model:0181", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:153", "@type": "Mapping", "id": "pack:153", "sourceEntry": "urn:business-engineer:source-entry:pack:153", "targetModel": "urn:business-engineer:model:0141", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:154", "@type": "Mapping", "id": "pack:154", "sourceEntry": "urn:business-engineer:source-entry:pack:154", "targetModel": "urn:business-engineer:model:0182", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:155", "@type": "Mapping", "id": "pack:155", "sourceEntry": "urn:business-engineer:source-entry:pack:155", "targetModel": "urn:business-engineer:model:0183", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:156", "@type": "Mapping", "id": "pack:156", "sourceEntry": "urn:business-engineer:source-entry:pack:156", "targetModel": "urn:business-engineer:model:0184", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:157", "@type": "Mapping", "id": "pack:157", "sourceEntry": "urn:business-engineer:source-entry:pack:157", "targetModel": "urn:business-engineer:model:0185", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:158", "@type": "Mapping", "id": "pack:158", "sourceEntry": "urn:business-engineer:source-entry:pack:158", "targetModel": "urn:business-engineer:model:0112", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:159", "@type": "Mapping", "id": "pack:159", "sourceEntry": "urn:business-engineer:source-entry:pack:159", "targetModel": "urn:business-engineer:model:0115", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:160", "@type": "Mapping", "id": "pack:160", "sourceEntry": "urn:business-engineer:source-entry:pack:160", "targetModel": "urn:business-engineer:model:0186", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:161", "@type": "Mapping", "id": "pack:161", "sourceEntry": "urn:business-engineer:source-entry:pack:161", "targetModel": "urn:business-engineer:model:0187", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:162", "@type": "Mapping", "id": "pack:162", "sourceEntry": "urn:business-engineer:source-entry:pack:162", "targetModel": "urn:business-engineer:model:0188", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:163", "@type": "Mapping", "id": "pack:163", "sourceEntry": "urn:business-engineer:source-entry:pack:163", "targetModel": "urn:business-engineer:model:0189", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:164", "@type": "Mapping", "id": "pack:164", "sourceEntry": "urn:business-engineer:source-entry:pack:164", "targetModel": "urn:business-engineer:model:0190", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:165", "@type": "Mapping", "id": "pack:165", "sourceEntry": "urn:business-engineer:source-entry:pack:165", "targetModel": "urn:business-engineer:model:0191", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:166", "@type": "Mapping", "id": "pack:166", "sourceEntry": "urn:business-engineer:source-entry:pack:166", "targetModel": "urn:business-engineer:model:0127", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:167", "@type": "Mapping", "id": "pack:167", "sourceEntry": "urn:business-engineer:source-entry:pack:167", "targetModel": "urn:business-engineer:model:0192", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:168", "@type": "Mapping", "id": "pack:168", "sourceEntry": "urn:business-engineer:source-entry:pack:168", "targetModel": "urn:business-engineer:model:0193", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:169", "@type": "Mapping", "id": "pack:169", "sourceEntry": "urn:business-engineer:source-entry:pack:169", "targetModel": "urn:business-engineer:model:0120", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:170", "@type": "Mapping", "id": "pack:170", "sourceEntry": "urn:business-engineer:source-entry:pack:170", "targetModel": "urn:business-engineer:model:0194", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:171", "@type": "Mapping", "id": "pack:171", "sourceEntry": "urn:business-engineer:source-entry:pack:171", "targetModel": "urn:business-engineer:model:0134", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:172", "@type": "Mapping", "id": "pack:172", "sourceEntry": "urn:business-engineer:source-entry:pack:172", "targetModel": "urn:business-engineer:model:0195", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:173", "@type": "Mapping", "id": "pack:173", "sourceEntry": "urn:business-engineer:source-entry:pack:173", "targetModel": "urn:business-engineer:model:0040", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:174", "@type": "Mapping", "id": "pack:174", "sourceEntry": "urn:business-engineer:source-entry:pack:174", "targetModel": "urn:business-engineer:model:0196", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:175", "@type": "Mapping", "id": "pack:175", "sourceEntry": "urn:business-engineer:source-entry:pack:175", "targetModel": "urn:business-engineer:model:0197", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:176", "@type": "Mapping", "id": "pack:176", "sourceEntry": "urn:business-engineer:source-entry:pack:176", "targetModel": "urn:business-engineer:model:0198", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:177", "@type": "Mapping", "id": "pack:177", "sourceEntry": "urn:business-engineer:source-entry:pack:177", "targetModel": "urn:business-engineer:model:0135", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:178", "@type": "Mapping", "id": "pack:178", "sourceEntry": "urn:business-engineer:source-entry:pack:178", "targetModel": "urn:business-engineer:model:0199", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:179", "@type": "Mapping", "id": "pack:179", "sourceEntry": "urn:business-engineer:source-entry:pack:179", "targetModel": "urn:business-engineer:model:0200", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:180", "@type": "Mapping", "id": "pack:180", "sourceEntry": "urn:business-engineer:source-entry:pack:180", "targetModel": "urn:business-engineer:model:0201", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:181", "@type": "Mapping", "id": "pack:181", "sourceEntry": "urn:business-engineer:source-entry:pack:181", "targetModel": "urn:business-engineer:model:0202", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:182", "@type": "Mapping", "id": "pack:182", "sourceEntry": "urn:business-engineer:source-entry:pack:182", "targetModel": "urn:business-engineer:model:0203", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:183", "@type": "Mapping", "id": "pack:183", "sourceEntry": "urn:business-engineer:source-entry:pack:183", "targetModel": "urn:business-engineer:model:0116", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:184", "@type": "Mapping", "id": "pack:184", "sourceEntry": "urn:business-engineer:source-entry:pack:184", "targetModel": "urn:business-engineer:model:0140", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:185", "@type": "Mapping", "id": "pack:185", "sourceEntry": "urn:business-engineer:source-entry:pack:185", "targetModel": "urn:business-engineer:model:0140", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:186", "@type": "Mapping", "id": "pack:186", "sourceEntry": "urn:business-engineer:source-entry:pack:186", "targetModel": "urn:business-engineer:model:0204", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:187", "@type": "Mapping", "id": "pack:187", "sourceEntry": "urn:business-engineer:source-entry:pack:187", "targetModel": "urn:business-engineer:model:0134", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:188", "@type": "Mapping", "id": "pack:188", "sourceEntry": "urn:business-engineer:source-entry:pack:188", "targetModel": "urn:business-engineer:model:0205", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:189", "@type": "Mapping", "id": "pack:189", "sourceEntry": "urn:business-engineer:source-entry:pack:189", "targetModel": "urn:business-engineer:model:0206", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:190", "@type": "Mapping", "id": "pack:190", "sourceEntry": "urn:business-engineer:source-entry:pack:190", "targetModel": "urn:business-engineer:model:0207", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:191", "@type": "Mapping", "id": "pack:191", "sourceEntry": "urn:business-engineer:source-entry:pack:191", "targetModel": "urn:business-engineer:model:0208", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:192", "@type": "Mapping", "id": "pack:192", "sourceEntry": "urn:business-engineer:source-entry:pack:192", "targetModel": "urn:business-engineer:model:0135", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:193", "@type": "Mapping", "id": "pack:193", "sourceEntry": "urn:business-engineer:source-entry:pack:193", "targetModel": "urn:business-engineer:model:0209", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:194", "@type": "Mapping", "id": "pack:194", "sourceEntry": "urn:business-engineer:source-entry:pack:194", "targetModel": "urn:business-engineer:model:0260", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:195", "@type": "Mapping", "id": "pack:195", "sourceEntry": "urn:business-engineer:source-entry:pack:195", "targetModel": "urn:business-engineer:model:0210", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:196", "@type": "Mapping", "id": "pack:196", "sourceEntry": "urn:business-engineer:source-entry:pack:196", "targetModel": "urn:business-engineer:model:0211", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:197", "@type": "Mapping", "id": "pack:197", "sourceEntry": "urn:business-engineer:source-entry:pack:197", "targetModel": "urn:business-engineer:model:0211", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:198", "@type": "Mapping", "id": "pack:198", "sourceEntry": "urn:business-engineer:source-entry:pack:198", "targetModel": "urn:business-engineer:model:0212", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:199", "@type": "Mapping", "id": "pack:199", "sourceEntry": "urn:business-engineer:source-entry:pack:199", "targetModel": "urn:business-engineer:model:0213", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:200", "@type": "Mapping", "id": "pack:200", "sourceEntry": "urn:business-engineer:source-entry:pack:200", "targetModel": "urn:business-engineer:model:0130", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:201", "@type": "Mapping", "id": "pack:201", "sourceEntry": "urn:business-engineer:source-entry:pack:201", "targetModel": "urn:business-engineer:model:0214", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:202", "@type": "Mapping", "id": "pack:202", "sourceEntry": "urn:business-engineer:source-entry:pack:202", "targetModel": "urn:business-engineer:model:0215", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:203", "@type": "Mapping", "id": "pack:203", "sourceEntry": "urn:business-engineer:source-entry:pack:203", "targetModel": "urn:business-engineer:model:0216", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:204", "@type": "Mapping", "id": "pack:204", "sourceEntry": "urn:business-engineer:source-entry:pack:204", "targetModel": "urn:business-engineer:model:0217", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:205", "@type": "Mapping", "id": "pack:205", "sourceEntry": "urn:business-engineer:source-entry:pack:205", "targetModel": "urn:business-engineer:model:0218", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:206", "@type": "Mapping", "id": "pack:206", "sourceEntry": "urn:business-engineer:source-entry:pack:206", "targetModel": "urn:business-engineer:model:0219", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:207", "@type": "Mapping", "id": "pack:207", "sourceEntry": "urn:business-engineer:source-entry:pack:207", "targetModel": "urn:business-engineer:model:0220", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:208", "@type": "Mapping", "id": "pack:208", "sourceEntry": "urn:business-engineer:source-entry:pack:208", "targetModel": "urn:business-engineer:model:0221", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:209", "@type": "Mapping", "id": "pack:209", "sourceEntry": "urn:business-engineer:source-entry:pack:209", "targetModel": "urn:business-engineer:model:0222", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:210", "@type": "Mapping", "id": "pack:210", "sourceEntry": "urn:business-engineer:source-entry:pack:210", "targetModel": "urn:business-engineer:model:0223", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:211", "@type": "Mapping", "id": "pack:211", "sourceEntry": "urn:business-engineer:source-entry:pack:211", "targetModel": "urn:business-engineer:model:0157", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:212", "@type": "Mapping", "id": "pack:212", "sourceEntry": "urn:business-engineer:source-entry:pack:212", "targetModel": "urn:business-engineer:model:0224", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:213", "@type": "Mapping", "id": "pack:213", "sourceEntry": "urn:business-engineer:source-entry:pack:213", "targetModel": "urn:business-engineer:model:0225", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:214", "@type": "Mapping", "id": "pack:214", "sourceEntry": "urn:business-engineer:source-entry:pack:214", "targetModel": "urn:business-engineer:model:0226", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:215", "@type": "Mapping", "id": "pack:215", "sourceEntry": "urn:business-engineer:source-entry:pack:215", "targetModel": "urn:business-engineer:model:0227", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:216", "@type": "Mapping", "id": "pack:216", "sourceEntry": "urn:business-engineer:source-entry:pack:216", "targetModel": "urn:business-engineer:model:0158", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:217", "@type": "Mapping", "id": "pack:217", "sourceEntry": "urn:business-engineer:source-entry:pack:217", "targetModel": "urn:business-engineer:model:0221", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:218", "@type": "Mapping", "id": "pack:218", "sourceEntry": "urn:business-engineer:source-entry:pack:218", "targetModel": "urn:business-engineer:model:0259", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:219", "@type": "Mapping", "id": "pack:219", "sourceEntry": "urn:business-engineer:source-entry:pack:219", "targetModel": "urn:business-engineer:model:0260", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:220", "@type": "Mapping", "id": "pack:220", "sourceEntry": "urn:business-engineer:source-entry:pack:220", "targetModel": "urn:business-engineer:model:0228", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:221", "@type": "Mapping", "id": "pack:221", "sourceEntry": "urn:business-engineer:source-entry:pack:221", "targetModel": "urn:business-engineer:model:0229", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:222", "@type": "Mapping", "id": "pack:222", "sourceEntry": "urn:business-engineer:source-entry:pack:222", "targetModel": "urn:business-engineer:model:0230", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:223", "@type": "Mapping", "id": "pack:223", "sourceEntry": "urn:business-engineer:source-entry:pack:223", "targetModel": "urn:business-engineer:model:0231", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:224", "@type": "Mapping", "id": "pack:224", "sourceEntry": "urn:business-engineer:source-entry:pack:224", "targetModel": "urn:business-engineer:model:0232", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:225", "@type": "Mapping", "id": "pack:225", "sourceEntry": "urn:business-engineer:source-entry:pack:225", "targetModel": "urn:business-engineer:model:0095", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:226", "@type": "Mapping", "id": "pack:226", "sourceEntry": "urn:business-engineer:source-entry:pack:226", "targetModel": "urn:business-engineer:model:0233", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:227", "@type": "Mapping", "id": "pack:227", "sourceEntry": "urn:business-engineer:source-entry:pack:227", "targetModel": "urn:business-engineer:model:0162", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:228", "@type": "Mapping", "id": "pack:228", "sourceEntry": "urn:business-engineer:source-entry:pack:228", "targetModel": "urn:business-engineer:model:0116", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:229", "@type": "Mapping", "id": "pack:229", "sourceEntry": "urn:business-engineer:source-entry:pack:229", "targetModel": "urn:business-engineer:model:0234", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:230", "@type": "Mapping", "id": "pack:230", "sourceEntry": "urn:business-engineer:source-entry:pack:230", "targetModel": "urn:business-engineer:model:0235", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:231", "@type": "Mapping", "id": "pack:231", "sourceEntry": "urn:business-engineer:source-entry:pack:231", "targetModel": "urn:business-engineer:model:0236", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:232", "@type": "Mapping", "id": "pack:232", "sourceEntry": "urn:business-engineer:source-entry:pack:232", "targetModel": "urn:business-engineer:model:0237", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:233", "@type": "Mapping", "id": "pack:233", "sourceEntry": "urn:business-engineer:source-entry:pack:233", "targetModel": "urn:business-engineer:model:0152", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:234", "@type": "Mapping", "id": "pack:234", "sourceEntry": "urn:business-engineer:source-entry:pack:234", "targetModel": "urn:business-engineer:model:0238", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:235", "@type": "Mapping", "id": "pack:235", "sourceEntry": "urn:business-engineer:source-entry:pack:235", "targetModel": "urn:business-engineer:model:0239", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:236", "@type": "Mapping", "id": "pack:236", "sourceEntry": "urn:business-engineer:source-entry:pack:236", "targetModel": "urn:business-engineer:model:0240", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:237", "@type": "Mapping", "id": "pack:237", "sourceEntry": "urn:business-engineer:source-entry:pack:237", "targetModel": "urn:business-engineer:model:0241", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:238", "@type": "Mapping", "id": "pack:238", "sourceEntry": "urn:business-engineer:source-entry:pack:238", "targetModel": "urn:business-engineer:model:0242", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:239", "@type": "Mapping", "id": "pack:239", "sourceEntry": "urn:business-engineer:source-entry:pack:239", "targetModel": "urn:business-engineer:model:0243", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:240", "@type": "Mapping", "id": "pack:240", "sourceEntry": "urn:business-engineer:source-entry:pack:240", "targetModel": "urn:business-engineer:model:0244", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:241", "@type": "Mapping", "id": "pack:241", "sourceEntry": "urn:business-engineer:source-entry:pack:241", "targetModel": "urn:business-engineer:model:0245", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:242", "@type": "Mapping", "id": "pack:242", "sourceEntry": "urn:business-engineer:source-entry:pack:242", "targetModel": "urn:business-engineer:model:0246", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:243", "@type": "Mapping", "id": "pack:243", "sourceEntry": "urn:business-engineer:source-entry:pack:243", "targetModel": "urn:business-engineer:model:0247", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:244", "@type": "Mapping", "id": "pack:244", "sourceEntry": "urn:business-engineer:source-entry:pack:244", "targetModel": "urn:business-engineer:model:0248", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:245", "@type": "Mapping", "id": "pack:245", "sourceEntry": "urn:business-engineer:source-entry:pack:245", "targetModel": "urn:business-engineer:model:0167", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:246", "@type": "Mapping", "id": "pack:246", "sourceEntry": "urn:business-engineer:source-entry:pack:246", "targetModel": "urn:business-engineer:model:0249", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:247", "@type": "Mapping", "id": "pack:247", "sourceEntry": "urn:business-engineer:source-entry:pack:247", "targetModel": "urn:business-engineer:model:0250", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:248", "@type": "Mapping", "id": "pack:248", "sourceEntry": "urn:business-engineer:source-entry:pack:248", "targetModel": "urn:business-engineer:model:0251", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:249", "@type": "Mapping", "id": "pack:249", "sourceEntry": "urn:business-engineer:source-entry:pack:249", "targetModel": "urn:business-engineer:model:0252", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:250", "@type": "Mapping", "id": "pack:250", "sourceEntry": "urn:business-engineer:source-entry:pack:250", "targetModel": "urn:business-engineer:model:0253", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:251", "@type": "Mapping", "id": "pack:251", "sourceEntry": "urn:business-engineer:source-entry:pack:251", "targetModel": "urn:business-engineer:model:0254", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:252", "@type": "Mapping", "id": "pack:252", "sourceEntry": "urn:business-engineer:source-entry:pack:252", "targetModel": "urn:business-engineer:model:0255", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:253", "@type": "Mapping", "id": "pack:253", "sourceEntry": "urn:business-engineer:source-entry:pack:253", "targetModel": "urn:business-engineer:model:0153", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:254", "@type": "Mapping", "id": "pack:254", "sourceEntry": "urn:business-engineer:source-entry:pack:254", "targetModel": "urn:business-engineer:model:0250", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:255", "@type": "Mapping", "id": "pack:255", "sourceEntry": "urn:business-engineer:source-entry:pack:255", "targetModel": "urn:business-engineer:model:0149", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:256", "@type": "Mapping", "id": "pack:256", "sourceEntry": "urn:business-engineer:source-entry:pack:256", "targetModel": "urn:business-engineer:model:0256", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:257", "@type": "Mapping", "id": "pack:257", "sourceEntry": "urn:business-engineer:source-entry:pack:257", "targetModel": "urn:business-engineer:model:0093", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:258", "@type": "Mapping", "id": "pack:258", "sourceEntry": "urn:business-engineer:source-entry:pack:258", "targetModel": "urn:business-engineer:model:0129", "mappingKind": "scopedVariant", "definition": "Attaches an application, additional dimension or narrower reading to an existing mechanism without asserting textual or logical equivalence." }, { "@id": "urn:business-engineer:mapping:pack:259", "@type": "Mapping", "id": "pack:259", "sourceEntry": "urn:business-engineer:source-entry:pack:259", "targetModel": "urn:business-engineer:model:0204", "mappingKind": "equivalentMechanism", "definition": "The source addresses the same underlying mechanism; wording and specific qualifications remain attached as provenance." }, { "@id": "urn:business-engineer:mapping:pack:260", "@type": "Mapping", "id": "pack:260", "sourceEntry": "urn:business-engineer:source-entry:pack:260", "targetModel": "urn:business-engineer:model:0257", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:mapping:pack:261", "@type": "Mapping", "id": "pack:261", "sourceEntry": "urn:business-engineer:source-entry:pack:261", "targetModel": "urn:business-engineer:model:0258", "mappingKind": "newMechanism", "definition": "Adds a distinct causal question or diagnostic absent from the prior canonical catalog." }, { "@id": "urn:business-engineer:relation:00001", "@type": "RelationAssertion", "id": "R00001", "subject": "urn:business-engineer:model:0001", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0002", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00002", "@type": "RelationAssertion", "id": "R00002", "subject": "urn:business-engineer:model:0001", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0003", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00003", "@type": "RelationAssertion", "id": "R00003", "subject": "urn:business-engineer:model:0001", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00004", "@type": "RelationAssertion", "id": "R00004", "subject": "urn:business-engineer:model:0001", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0008", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00005", "@type": "RelationAssertion", "id": "R00005", "subject": "urn:business-engineer:model:0002", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00006", "@type": "RelationAssertion", "id": "R00006", "subject": "urn:business-engineer:model:0002", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0012", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00007", "@type": "RelationAssertion", "id": "R00007", "subject": "urn:business-engineer:model:0002", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0020", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00008", "@type": "RelationAssertion", "id": "R00008", "subject": "urn:business-engineer:model:0003", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0005", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00009", "@type": "RelationAssertion", "id": "R00009", "subject": "urn:business-engineer:model:0003", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0023", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00010", "@type": "RelationAssertion", "id": "R00010", "subject": "urn:business-engineer:model:0004", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00011", "@type": "RelationAssertion", "id": "R00011", "subject": "urn:business-engineer:model:0004", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0009", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00012", "@type": "RelationAssertion", "id": "R00012", "subject": "urn:business-engineer:model:0005", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0018", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00013", "@type": "RelationAssertion", "id": "R00013", "subject": "urn:business-engineer:model:0006", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00014", "@type": "RelationAssertion", "id": "R00014", "subject": "urn:business-engineer:model:0006", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00015", "@type": "RelationAssertion", "id": "R00015", "subject": "urn:business-engineer:model:0006", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0010", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00016", "@type": "RelationAssertion", "id": "R00016", "subject": "urn:business-engineer:model:0007", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00017", "@type": "RelationAssertion", "id": "R00017", "subject": "urn:business-engineer:model:0007", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0013", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00018", "@type": "RelationAssertion", "id": "R00018", "subject": "urn:business-engineer:model:0008", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0167", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00019", "@type": "RelationAssertion", "id": "R00019", "subject": "urn:business-engineer:model:0008", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0018", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00020", "@type": "RelationAssertion", "id": "R00020", "subject": "urn:business-engineer:model:0009", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0003", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00021", "@type": "RelationAssertion", "id": "R00021", "subject": "urn:business-engineer:model:0010", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00022", "@type": "RelationAssertion", "id": "R00022", "subject": "urn:business-engineer:model:0010", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00023", "@type": "RelationAssertion", "id": "R00023", "subject": "urn:business-engineer:model:0011", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0012", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00024", "@type": "RelationAssertion", "id": "R00024", "subject": "urn:business-engineer:model:0011", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0021", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00025", "@type": "RelationAssertion", "id": "R00025", "subject": "urn:business-engineer:model:0012", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0015", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00026", "@type": "RelationAssertion", "id": "R00026", "subject": "urn:business-engineer:model:0012", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0020", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00027", "@type": "RelationAssertion", "id": "R00027", "subject": "urn:business-engineer:model:0013", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00028", "@type": "RelationAssertion", "id": "R00028", "subject": "urn:business-engineer:model:0013", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0079", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00029", "@type": "RelationAssertion", "id": "R00029", "subject": "urn:business-engineer:model:0013", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00030", "@type": "RelationAssertion", "id": "R00030", "subject": "urn:business-engineer:model:0014", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0159", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00031", "@type": "RelationAssertion", "id": "R00031", "subject": "urn:business-engineer:model:0014", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00032", "@type": "RelationAssertion", "id": "R00032", "subject": "urn:business-engineer:model:0015", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0168", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00033", "@type": "RelationAssertion", "id": "R00033", "subject": "urn:business-engineer:model:0015", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0019", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00034", "@type": "RelationAssertion", "id": "R00034", "subject": "urn:business-engineer:model:0015", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00035", "@type": "RelationAssertion", "id": "R00035", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0139", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00036", "@type": "RelationAssertion", "id": "R00036", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0140", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00037", "@type": "RelationAssertion", "id": "R00037", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0147", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00038", "@type": "RelationAssertion", "id": "R00038", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0149", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00039", "@type": "RelationAssertion", "id": "R00039", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0154", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00040", "@type": "RelationAssertion", "id": "R00040", "subject": "urn:business-engineer:model:0016", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0094", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00041", "@type": "RelationAssertion", "id": "R00041", "subject": "urn:business-engineer:model:0017", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0142", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00042", "@type": "RelationAssertion", "id": "R00042", "subject": "urn:business-engineer:model:0017", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0034", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00043", "@type": "RelationAssertion", "id": "R00043", "subject": "urn:business-engineer:model:0018", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0138", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00044", "@type": "RelationAssertion", "id": "R00044", "subject": "urn:business-engineer:model:0018", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0139", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00045", "@type": "RelationAssertion", "id": "R00045", "subject": "urn:business-engineer:model:0018", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00046", "@type": "RelationAssertion", "id": "R00046", "subject": "urn:business-engineer:model:0019", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00047", "@type": "RelationAssertion", "id": "R00047", "subject": "urn:business-engineer:model:0020", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00048", "@type": "RelationAssertion", "id": "R00048", "subject": "urn:business-engineer:model:0020", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0021", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00049", "@type": "RelationAssertion", "id": "R00049", "subject": "urn:business-engineer:model:0021", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00050", "@type": "RelationAssertion", "id": "R00050", "subject": "urn:business-engineer:model:0021", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0022", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00051", "@type": "RelationAssertion", "id": "R00051", "subject": "urn:business-engineer:model:0022", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0025", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00052", "@type": "RelationAssertion", "id": "R00052", "subject": "urn:business-engineer:model:0023", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0141", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00053", "@type": "RelationAssertion", "id": "R00053", "subject": "urn:business-engineer:model:0023", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0026", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00054", "@type": "RelationAssertion", "id": "R00054", "subject": "urn:business-engineer:model:0023", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00055", "@type": "RelationAssertion", "id": "R00055", "subject": "urn:business-engineer:model:0024", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0073", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00056", "@type": "RelationAssertion", "id": "R00056", "subject": "urn:business-engineer:model:0024", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0075", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00057", "@type": "RelationAssertion", "id": "R00057", "subject": "urn:business-engineer:model:0025", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0032", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00058", "@type": "RelationAssertion", "id": "R00058", "subject": "urn:business-engineer:model:0026", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0086", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00059", "@type": "RelationAssertion", "id": "R00059", "subject": "urn:business-engineer:model:0027", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0164", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00060", "@type": "RelationAssertion", "id": "R00060", "subject": "urn:business-engineer:model:0027", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0078", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00061", "@type": "RelationAssertion", "id": "R00061", "subject": "urn:business-engineer:model:0028", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0029", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00062", "@type": "RelationAssertion", "id": "R00062", "subject": "urn:business-engineer:model:0028", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00063", "@type": "RelationAssertion", "id": "R00063", "subject": "urn:business-engineer:model:0028", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0032", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00064", "@type": "RelationAssertion", "id": "R00064", "subject": "urn:business-engineer:model:0029", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00065", "@type": "RelationAssertion", "id": "R00065", "subject": "urn:business-engineer:model:0029", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0046", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00066", "@type": "RelationAssertion", "id": "R00066", "subject": "urn:business-engineer:model:0030", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00067", "@type": "RelationAssertion", "id": "R00067", "subject": "urn:business-engineer:model:0030", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0031", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00068", "@type": "RelationAssertion", "id": "R00068", "subject": "urn:business-engineer:model:0031", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0150", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00069", "@type": "RelationAssertion", "id": "R00069", "subject": "urn:business-engineer:model:0031", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0032", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00070", "@type": "RelationAssertion", "id": "R00070", "subject": "urn:business-engineer:model:0032", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0144", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00071", "@type": "RelationAssertion", "id": "R00071", "subject": "urn:business-engineer:model:0032", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0036", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00072", "@type": "RelationAssertion", "id": "R00072", "subject": "urn:business-engineer:model:0032", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00073", "@type": "RelationAssertion", "id": "R00073", "subject": "urn:business-engineer:model:0033", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0155", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00074", "@type": "RelationAssertion", "id": "R00074", "subject": "urn:business-engineer:model:0033", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0034", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00075", "@type": "RelationAssertion", "id": "R00075", "subject": "urn:business-engineer:model:0034", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00076", "@type": "RelationAssertion", "id": "R00076", "subject": "urn:business-engineer:model:0034", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00077", "@type": "RelationAssertion", "id": "R00077", "subject": "urn:business-engineer:model:0034", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0035", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00078", "@type": "RelationAssertion", "id": "R00078", "subject": "urn:business-engineer:model:0035", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0150", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00079", "@type": "RelationAssertion", "id": "R00079", "subject": "urn:business-engineer:model:0035", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0156", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00080", "@type": "RelationAssertion", "id": "R00080", "subject": "urn:business-engineer:model:0035", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0161", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00081", "@type": "RelationAssertion", "id": "R00081", "subject": "urn:business-engineer:model:0035", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0037", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00082", "@type": "RelationAssertion", "id": "R00082", "subject": "urn:business-engineer:model:0036", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00083", "@type": "RelationAssertion", "id": "R00083", "subject": "urn:business-engineer:model:0036", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0167", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00084", "@type": "RelationAssertion", "id": "R00084", "subject": "urn:business-engineer:model:0037", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0160", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00085", "@type": "RelationAssertion", "id": "R00085", "subject": "urn:business-engineer:model:0037", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0165", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00086", "@type": "RelationAssertion", "id": "R00086", "subject": "urn:business-engineer:model:0037", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0075", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00087", "@type": "RelationAssertion", "id": "R00087", "subject": "urn:business-engineer:model:0038", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0039", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00088", "@type": "RelationAssertion", "id": "R00088", "subject": "urn:business-engineer:model:0038", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0041", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00089", "@type": "RelationAssertion", "id": "R00089", "subject": "urn:business-engineer:model:0039", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0040", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00090", "@type": "RelationAssertion", "id": "R00090", "subject": "urn:business-engineer:model:0039", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0060", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00091", "@type": "RelationAssertion", "id": "R00091", "subject": "urn:business-engineer:model:0040", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0041", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00092", "@type": "RelationAssertion", "id": "R00092", "subject": "urn:business-engineer:model:0040", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0063", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00093", "@type": "RelationAssertion", "id": "R00093", "subject": "urn:business-engineer:model:0041", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0046", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00094", "@type": "RelationAssertion", "id": "R00094", "subject": "urn:business-engineer:model:0041", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0089", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00095", "@type": "RelationAssertion", "id": "R00095", "subject": "urn:business-engineer:model:0042", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0045", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00096", "@type": "RelationAssertion", "id": "R00096", "subject": "urn:business-engineer:model:0042", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0091", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00097", "@type": "RelationAssertion", "id": "R00097", "subject": "urn:business-engineer:model:0043", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0138", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00098", "@type": "RelationAssertion", "id": "R00098", "subject": "urn:business-engineer:model:0043", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0044", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00099", "@type": "RelationAssertion", "id": "R00099", "subject": "urn:business-engineer:model:0043", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0066", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00100", "@type": "RelationAssertion", "id": "R00100", "subject": "urn:business-engineer:model:0044", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0097", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00101", "@type": "RelationAssertion", "id": "R00101", "subject": "urn:business-engineer:model:0045", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0152", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00102", "@type": "RelationAssertion", "id": "R00102", "subject": "urn:business-engineer:model:0046", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0152", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00103", "@type": "RelationAssertion", "id": "R00103", "subject": "urn:business-engineer:model:0046", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0047", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00104", "@type": "RelationAssertion", "id": "R00104", "subject": "urn:business-engineer:model:0046", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0089", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00105", "@type": "RelationAssertion", "id": "R00105", "subject": "urn:business-engineer:model:0047", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0159", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00106", "@type": "RelationAssertion", "id": "R00106", "subject": "urn:business-engineer:model:0048", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0013", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00107", "@type": "RelationAssertion", "id": "R00107", "subject": "urn:business-engineer:model:0048", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0020", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00108", "@type": "RelationAssertion", "id": "R00108", "subject": "urn:business-engineer:model:0049", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0050", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00109", "@type": "RelationAssertion", "id": "R00109", "subject": "urn:business-engineer:model:0049", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0063", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00110", "@type": "RelationAssertion", "id": "R00110", "subject": "urn:business-engineer:model:0050", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0057", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00111", "@type": "RelationAssertion", "id": "R00111", "subject": "urn:business-engineer:model:0050", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0107", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00112", "@type": "RelationAssertion", "id": "R00112", "subject": "urn:business-engineer:model:0051", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0040", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00113", "@type": "RelationAssertion", "id": "R00113", "subject": "urn:business-engineer:model:0051", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0062", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00114", "@type": "RelationAssertion", "id": "R00114", "subject": "urn:business-engineer:model:0052", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0154", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00115", "@type": "RelationAssertion", "id": "R00115", "subject": "urn:business-engineer:model:0052", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00116", "@type": "RelationAssertion", "id": "R00116", "subject": "urn:business-engineer:model:0053", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0142", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00117", "@type": "RelationAssertion", "id": "R00117", "subject": "urn:business-engineer:model:0053", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0146", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00118", "@type": "RelationAssertion", "id": "R00118", "subject": "urn:business-engineer:model:0054", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0148", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00119", "@type": "RelationAssertion", "id": "R00119", "subject": "urn:business-engineer:model:0054", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0058", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00120", "@type": "RelationAssertion", "id": "R00120", "subject": "urn:business-engineer:model:0055", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00121", "@type": "RelationAssertion", "id": "R00121", "subject": "urn:business-engineer:model:0055", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0041", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00122", "@type": "RelationAssertion", "id": "R00122", "subject": "urn:business-engineer:model:0056", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0082", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00123", "@type": "RelationAssertion", "id": "R00123", "subject": "urn:business-engineer:model:0056", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0087", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00124", "@type": "RelationAssertion", "id": "R00124", "subject": "urn:business-engineer:model:0057", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0139", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00125", "@type": "RelationAssertion", "id": "R00125", "subject": "urn:business-engineer:model:0057", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0166", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00126", "@type": "RelationAssertion", "id": "R00126", "subject": "urn:business-engineer:model:0057", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0060", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00127", "@type": "RelationAssertion", "id": "R00127", "subject": "urn:business-engineer:model:0058", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0146", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00128", "@type": "RelationAssertion", "id": "R00128", "subject": "urn:business-engineer:model:0059", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0057", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00129", "@type": "RelationAssertion", "id": "R00129", "subject": "urn:business-engineer:model:0059", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0062", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00130", "@type": "RelationAssertion", "id": "R00130", "subject": "urn:business-engineer:model:0060", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00131", "@type": "RelationAssertion", "id": "R00131", "subject": "urn:business-engineer:model:0061", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00132", "@type": "RelationAssertion", "id": "R00132", "subject": "urn:business-engineer:model:0061", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0097", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00133", "@type": "RelationAssertion", "id": "R00133", "subject": "urn:business-engineer:model:0062", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0034", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00134", "@type": "RelationAssertion", "id": "R00134", "subject": "urn:business-engineer:model:0062", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0063", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00135", "@type": "RelationAssertion", "id": "R00135", "subject": "urn:business-engineer:model:0063", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00136", "@type": "RelationAssertion", "id": "R00136", "subject": "urn:business-engineer:model:0063", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0064", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00137", "@type": "RelationAssertion", "id": "R00137", "subject": "urn:business-engineer:model:0064", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0085", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00138", "@type": "RelationAssertion", "id": "R00138", "subject": "urn:business-engineer:model:0065", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0047", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00139", "@type": "RelationAssertion", "id": "R00139", "subject": "urn:business-engineer:model:0065", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0066", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00140", "@type": "RelationAssertion", "id": "R00140", "subject": "urn:business-engineer:model:0066", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0155", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00141", "@type": "RelationAssertion", "id": "R00141", "subject": "urn:business-engineer:model:0066", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0157", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00142", "@type": "RelationAssertion", "id": "R00142", "subject": "urn:business-engineer:model:0067", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0026", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00143", "@type": "RelationAssertion", "id": "R00143", "subject": "urn:business-engineer:model:0067", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0086", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00144", "@type": "RelationAssertion", "id": "R00144", "subject": "urn:business-engineer:model:0068", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0023", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00145", "@type": "RelationAssertion", "id": "R00145", "subject": "urn:business-engineer:model:0068", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0093", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00146", "@type": "RelationAssertion", "id": "R00146", "subject": "urn:business-engineer:model:0069", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0092", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00147", "@type": "RelationAssertion", "id": "R00147", "subject": "urn:business-engineer:model:0069", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00148", "@type": "RelationAssertion", "id": "R00148", "subject": "urn:business-engineer:model:0071", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0064", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00149", "@type": "RelationAssertion", "id": "R00149", "subject": "urn:business-engineer:model:0071", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00150", "@type": "RelationAssertion", "id": "R00150", "subject": "urn:business-engineer:model:0072", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0084", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00151", "@type": "RelationAssertion", "id": "R00151", "subject": "urn:business-engineer:model:0072", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0086", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00152", "@type": "RelationAssertion", "id": "R00152", "subject": "urn:business-engineer:model:0073", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0101", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00153", "@type": "RelationAssertion", "id": "R00153", "subject": "urn:business-engineer:model:0075", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0164", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00154", "@type": "RelationAssertion", "id": "R00154", "subject": "urn:business-engineer:model:0075", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0165", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00155", "@type": "RelationAssertion", "id": "R00155", "subject": "urn:business-engineer:model:0076", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0077", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00156", "@type": "RelationAssertion", "id": "R00156", "subject": "urn:business-engineer:model:0076", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0078", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00157", "@type": "RelationAssertion", "id": "R00157", "subject": "urn:business-engineer:model:0077", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0165", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00158", "@type": "RelationAssertion", "id": "R00158", "subject": "urn:business-engineer:model:0078", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0167", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00159", "@type": "RelationAssertion", "id": "R00159", "subject": "urn:business-engineer:model:0079", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0014", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00160", "@type": "RelationAssertion", "id": "R00160", "subject": "urn:business-engineer:model:0079", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00161", "@type": "RelationAssertion", "id": "R00161", "subject": "urn:business-engineer:model:0080", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0164", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00162", "@type": "RelationAssertion", "id": "R00162", "subject": "urn:business-engineer:model:0080", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0014", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00163", "@type": "RelationAssertion", "id": "R00163", "subject": "urn:business-engineer:model:0081", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0082", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00164", "@type": "RelationAssertion", "id": "R00164", "subject": "urn:business-engineer:model:0081", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00165", "@type": "RelationAssertion", "id": "R00165", "subject": "urn:business-engineer:model:0082", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00166", "@type": "RelationAssertion", "id": "R00166", "subject": "urn:business-engineer:model:0082", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0168", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00167", "@type": "RelationAssertion", "id": "R00167", "subject": "urn:business-engineer:model:0082", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0087", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00168", "@type": "RelationAssertion", "id": "R00168", "subject": "urn:business-engineer:model:0083", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0027", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00169", "@type": "RelationAssertion", "id": "R00169", "subject": "urn:business-engineer:model:0083", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00170", "@type": "RelationAssertion", "id": "R00170", "subject": "urn:business-engineer:model:0084", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0154", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00171", "@type": "RelationAssertion", "id": "R00171", "subject": "urn:business-engineer:model:0084", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00172", "@type": "RelationAssertion", "id": "R00172", "subject": "urn:business-engineer:model:0084", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0142", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00173", "@type": "RelationAssertion", "id": "R00173", "subject": "urn:business-engineer:model:0085", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0156", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00174", "@type": "RelationAssertion", "id": "R00174", "subject": "urn:business-engineer:model:0085", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0160", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00175", "@type": "RelationAssertion", "id": "R00175", "subject": "urn:business-engineer:model:0087", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0168", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00176", "@type": "RelationAssertion", "id": "R00176", "subject": "urn:business-engineer:model:0087", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00177", "@type": "RelationAssertion", "id": "R00177", "subject": "urn:business-engineer:model:0088", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0082", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00178", "@type": "RelationAssertion", "id": "R00178", "subject": "urn:business-engineer:model:0088", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00179", "@type": "RelationAssertion", "id": "R00179", "subject": "urn:business-engineer:model:0089", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0141", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00180", "@type": "RelationAssertion", "id": "R00180", "subject": "urn:business-engineer:model:0090", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0049", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00181", "@type": "RelationAssertion", "id": "R00181", "subject": "urn:business-engineer:model:0090", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0050", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00182", "@type": "RelationAssertion", "id": "R00182", "subject": "urn:business-engineer:model:0091", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0114", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00183", "@type": "RelationAssertion", "id": "R00183", "subject": "urn:business-engineer:model:0092", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0122", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00184", "@type": "RelationAssertion", "id": "R00184", "subject": "urn:business-engineer:model:0093", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00185", "@type": "RelationAssertion", "id": "R00185", "subject": "urn:business-engineer:model:0094", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0140", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00186", "@type": "RelationAssertion", "id": "R00186", "subject": "urn:business-engineer:model:0094", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0152", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00187", "@type": "RelationAssertion", "id": "R00187", "subject": "urn:business-engineer:model:0094", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0166", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00188", "@type": "RelationAssertion", "id": "R00188", "subject": "urn:business-engineer:model:0095", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0066", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00189", "@type": "RelationAssertion", "id": "R00189", "subject": "urn:business-engineer:model:0095", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0114", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00190", "@type": "RelationAssertion", "id": "R00190", "subject": "urn:business-engineer:model:0096", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0146", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00191", "@type": "RelationAssertion", "id": "R00191", "subject": "urn:business-engineer:model:0096", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00192", "@type": "RelationAssertion", "id": "R00192", "subject": "urn:business-engineer:model:0097", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00193", "@type": "RelationAssertion", "id": "R00193", "subject": "urn:business-engineer:model:0098", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0039", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00194", "@type": "RelationAssertion", "id": "R00194", "subject": "urn:business-engineer:model:0098", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0096", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00195", "@type": "RelationAssertion", "id": "R00195", "subject": "urn:business-engineer:model:0099", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0053", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00196", "@type": "RelationAssertion", "id": "R00196", "subject": "urn:business-engineer:model:0099", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0096", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00197", "@type": "RelationAssertion", "id": "R00197", "subject": "urn:business-engineer:model:0100", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00198", "@type": "RelationAssertion", "id": "R00198", "subject": "urn:business-engineer:model:0100", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0097", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00199", "@type": "RelationAssertion", "id": "R00199", "subject": "urn:business-engineer:model:0101", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0037", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00200", "@type": "RelationAssertion", "id": "R00200", "subject": "urn:business-engineer:model:0102", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0083", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00201", "@type": "RelationAssertion", "id": "R00201", "subject": "urn:business-engineer:model:0102", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0110", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00202", "@type": "RelationAssertion", "id": "R00202", "subject": "urn:business-engineer:model:0103", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0002", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00203", "@type": "RelationAssertion", "id": "R00203", "subject": "urn:business-engineer:model:0103", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0167", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00204", "@type": "RelationAssertion", "id": "R00204", "subject": "urn:business-engineer:model:0104", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0092", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00205", "@type": "RelationAssertion", "id": "R00205", "subject": "urn:business-engineer:model:0104", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0112", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00206", "@type": "RelationAssertion", "id": "R00206", "subject": "urn:business-engineer:model:0105", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0063", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00207", "@type": "RelationAssertion", "id": "R00207", "subject": "urn:business-engineer:model:0105", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0073", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00208", "@type": "RelationAssertion", "id": "R00208", "subject": "urn:business-engineer:model:0106", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0029", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00209", "@type": "RelationAssertion", "id": "R00209", "subject": "urn:business-engineer:model:0106", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0048", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00210", "@type": "RelationAssertion", "id": "R00210", "subject": "urn:business-engineer:model:0107", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0035", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00211", "@type": "RelationAssertion", "id": "R00211", "subject": "urn:business-engineer:model:0108", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0037", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00212", "@type": "RelationAssertion", "id": "R00212", "subject": "urn:business-engineer:model:0108", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00213", "@type": "RelationAssertion", "id": "R00213", "subject": "urn:business-engineer:model:0109", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0004", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00214", "@type": "RelationAssertion", "id": "R00214", "subject": "urn:business-engineer:model:0109", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00215", "@type": "RelationAssertion", "id": "R00215", "subject": "urn:business-engineer:model:0110", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00216", "@type": "RelationAssertion", "id": "R00216", "subject": "urn:business-engineer:model:0110", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0166", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00217", "@type": "RelationAssertion", "id": "R00217", "subject": "urn:business-engineer:model:0111", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0112", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00218", "@type": "RelationAssertion", "id": "R00218", "subject": "urn:business-engineer:model:0111", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0115", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00219", "@type": "RelationAssertion", "id": "R00219", "subject": "urn:business-engineer:model:0112", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0133", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00220", "@type": "RelationAssertion", "id": "R00220", "subject": "urn:business-engineer:model:0113", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0118", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00221", "@type": "RelationAssertion", "id": "R00221", "subject": "urn:business-engineer:model:0113", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0125", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00222", "@type": "RelationAssertion", "id": "R00222", "subject": "urn:business-engineer:model:0114", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0115", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00223", "@type": "RelationAssertion", "id": "R00223", "subject": "urn:business-engineer:model:0114", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0121", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00224", "@type": "RelationAssertion", "id": "R00224", "subject": "urn:business-engineer:model:0115", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0157", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00225", "@type": "RelationAssertion", "id": "R00225", "subject": "urn:business-engineer:model:0116", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0111", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00226", "@type": "RelationAssertion", "id": "R00226", "subject": "urn:business-engineer:model:0116", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0115", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00227", "@type": "RelationAssertion", "id": "R00227", "subject": "urn:business-engineer:model:0117", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00228", "@type": "RelationAssertion", "id": "R00228", "subject": "urn:business-engineer:model:0117", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0136", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00229", "@type": "RelationAssertion", "id": "R00229", "subject": "urn:business-engineer:model:0118", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0125", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00230", "@type": "RelationAssertion", "id": "R00230", "subject": "urn:business-engineer:model:0119", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0123", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00231", "@type": "RelationAssertion", "id": "R00231", "subject": "urn:business-engineer:model:0119", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0126", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00232", "@type": "RelationAssertion", "id": "R00232", "subject": "urn:business-engineer:model:0120", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0113", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00233", "@type": "RelationAssertion", "id": "R00233", "subject": "urn:business-engineer:model:0120", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0119", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00234", "@type": "RelationAssertion", "id": "R00234", "subject": "urn:business-engineer:model:0121", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0125", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00235", "@type": "RelationAssertion", "id": "R00235", "subject": "urn:business-engineer:model:0122", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0123", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00236", "@type": "RelationAssertion", "id": "R00236", "subject": "urn:business-engineer:model:0122", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00237", "@type": "RelationAssertion", "id": "R00237", "subject": "urn:business-engineer:model:0123", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0124", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00238", "@type": "RelationAssertion", "id": "R00238", "subject": "urn:business-engineer:model:0123", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0126", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00239", "@type": "RelationAssertion", "id": "R00239", "subject": "urn:business-engineer:model:0124", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0121", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00240", "@type": "RelationAssertion", "id": "R00240", "subject": "urn:business-engineer:model:0125", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0112", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00241", "@type": "RelationAssertion", "id": "R00241", "subject": "urn:business-engineer:model:0125", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00242", "@type": "RelationAssertion", "id": "R00242", "subject": "urn:business-engineer:model:0127", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0128", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00243", "@type": "RelationAssertion", "id": "R00243", "subject": "urn:business-engineer:model:0127", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00244", "@type": "RelationAssertion", "id": "R00244", "subject": "urn:business-engineer:model:0128", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0132", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00245", "@type": "RelationAssertion", "id": "R00245", "subject": "urn:business-engineer:model:0128", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0134", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00246", "@type": "RelationAssertion", "id": "R00246", "subject": "urn:business-engineer:model:0129", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0043", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00247", "@type": "RelationAssertion", "id": "R00247", "subject": "urn:business-engineer:model:0129", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00248", "@type": "RelationAssertion", "id": "R00248", "subject": "urn:business-engineer:model:0130", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00249", "@type": "RelationAssertion", "id": "R00249", "subject": "urn:business-engineer:model:0130", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00250", "@type": "RelationAssertion", "id": "R00250", "subject": "urn:business-engineer:model:0131", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0141", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00251", "@type": "RelationAssertion", "id": "R00251", "subject": "urn:business-engineer:model:0131", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0161", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00252", "@type": "RelationAssertion", "id": "R00252", "subject": "urn:business-engineer:model:0131", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00253", "@type": "RelationAssertion", "id": "R00253", "subject": "urn:business-engineer:model:0131", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0132", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00254", "@type": "RelationAssertion", "id": "R00254", "subject": "urn:business-engineer:model:0132", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0134", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00255", "@type": "RelationAssertion", "id": "R00255", "subject": "urn:business-engineer:model:0133", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00256", "@type": "RelationAssertion", "id": "R00256", "subject": "urn:business-engineer:model:0134", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0060", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00257", "@type": "RelationAssertion", "id": "R00257", "subject": "urn:business-engineer:model:0135", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0140", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00258", "@type": "RelationAssertion", "id": "R00258", "subject": "urn:business-engineer:model:0135", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0144", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00259", "@type": "RelationAssertion", "id": "R00259", "subject": "urn:business-engineer:model:0135", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0166", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00260", "@type": "RelationAssertion", "id": "R00260", "subject": "urn:business-engineer:model:0135", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0136", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00261", "@type": "RelationAssertion", "id": "R00261", "subject": "urn:business-engineer:model:0135", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00262", "@type": "RelationAssertion", "id": "R00262", "subject": "urn:business-engineer:model:0136", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0148", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00263", "@type": "RelationAssertion", "id": "R00263", "subject": "urn:business-engineer:model:0136", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0149", "definition": "Prior catalog relation: extended/tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00264", "@type": "RelationAssertion", "id": "R00264", "subject": "urn:business-engineer:model:0137", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0063", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00265", "@type": "RelationAssertion", "id": "R00265", "subject": "urn:business-engineer:model:0137", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0093", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00266", "@type": "RelationAssertion", "id": "R00266", "subject": "urn:business-engineer:model:0137", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0130", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00267", "@type": "RelationAssertion", "id": "R00267", "subject": "urn:business-engineer:model:0137", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0167", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00268", "@type": "RelationAssertion", "id": "R00268", "subject": "urn:business-engineer:model:0138", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0018", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00269", "@type": "RelationAssertion", "id": "R00269", "subject": "urn:business-engineer:model:0138", "predicate": "urn:business-engineer:relation-type:analogousTo", "object": "urn:business-engineer:model:0043", "definition": "Prior catalog relation: analogous to. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00270", "@type": "RelationAssertion", "id": "R00270", "subject": "urn:business-engineer:model:0138", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00271", "@type": "RelationAssertion", "id": "R00271", "subject": "urn:business-engineer:model:0139", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0138", "definition": "Prior catalog relation: qualified by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00272", "@type": "RelationAssertion", "id": "R00272", "subject": "urn:business-engineer:model:0139", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00273", "@type": "RelationAssertion", "id": "R00273", "subject": "urn:business-engineer:model:0139", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0018", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00274", "@type": "RelationAssertion", "id": "R00274", "subject": "urn:business-engineer:model:0139", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0057", "definition": "Prior catalog relation: applies to. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00275", "@type": "RelationAssertion", "id": "R00275", "subject": "urn:business-engineer:model:0139", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0141", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00276", "@type": "RelationAssertion", "id": "R00276", "subject": "urn:business-engineer:model:0140", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00277", "@type": "RelationAssertion", "id": "R00277", "subject": "urn:business-engineer:model:0140", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0094", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00278", "@type": "RelationAssertion", "id": "R00278", "subject": "urn:business-engineer:model:0140", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00279", "@type": "RelationAssertion", "id": "R00279", "subject": "urn:business-engineer:model:0140", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0148", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00280", "@type": "RelationAssertion", "id": "R00280", "subject": "urn:business-engineer:model:0141", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0023", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00281", "@type": "RelationAssertion", "id": "R00281", "subject": "urn:business-engineer:model:0141", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0089", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00282", "@type": "RelationAssertion", "id": "R00282", "subject": "urn:business-engineer:model:0141", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00283", "@type": "RelationAssertion", "id": "R00283", "subject": "urn:business-engineer:model:0141", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0138", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00284", "@type": "RelationAssertion", "id": "R00284", "subject": "urn:business-engineer:model:0142", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0017", "definition": "Prior catalog relation: addresses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00285", "@type": "RelationAssertion", "id": "R00285", "subject": "urn:business-engineer:model:0142", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0053", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00286", "@type": "RelationAssertion", "id": "R00286", "subject": "urn:business-engineer:model:0142", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0143", "definition": "Prior catalog relation: feeds. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00287", "@type": "RelationAssertion", "id": "R00287", "subject": "urn:business-engineer:model:0142", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: supported by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00288", "@type": "RelationAssertion", "id": "R00288", "subject": "urn:business-engineer:model:0143", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0142", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00289", "@type": "RelationAssertion", "id": "R00289", "subject": "urn:business-engineer:model:0143", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0148", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00290", "@type": "RelationAssertion", "id": "R00290", "subject": "urn:business-engineer:model:0156", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0143", "definition": "Prior catalog relation: qualified by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00291", "@type": "RelationAssertion", "id": "R00291", "subject": "urn:business-engineer:model:0143", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0160", "definition": "Prior catalog relation: bounded by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00292", "@type": "RelationAssertion", "id": "R00292", "subject": "urn:business-engineer:model:0144", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0032", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00293", "@type": "RelationAssertion", "id": "R00293", "subject": "urn:business-engineer:model:0144", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00294", "@type": "RelationAssertion", "id": "R00294", "subject": "urn:business-engineer:model:0144", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0143", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00295", "@type": "RelationAssertion", "id": "R00295", "subject": "urn:business-engineer:model:0144", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00296", "@type": "RelationAssertion", "id": "R00296", "subject": "urn:business-engineer:model:0145", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0034", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00297", "@type": "RelationAssertion", "id": "R00297", "subject": "urn:business-engineer:model:0145", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0036", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00298", "@type": "RelationAssertion", "id": "R00298", "subject": "urn:business-engineer:model:0145", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0144", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00299", "@type": "RelationAssertion", "id": "R00299", "subject": "urn:business-engineer:model:0145", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0155", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00300", "@type": "RelationAssertion", "id": "R00300", "subject": "urn:business-engineer:model:0146", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0053", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00301", "@type": "RelationAssertion", "id": "R00301", "subject": "urn:business-engineer:model:0146", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0058", "definition": "Prior catalog relation: refines. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00302", "@type": "RelationAssertion", "id": "R00302", "subject": "urn:business-engineer:model:0146", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0096", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00303", "@type": "RelationAssertion", "id": "R00303", "subject": "urn:business-engineer:model:0146", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0147", "definition": "Prior catalog relation: bounded by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00304", "@type": "RelationAssertion", "id": "R00304", "subject": "urn:business-engineer:model:0147", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00305", "@type": "RelationAssertion", "id": "R00305", "subject": "urn:business-engineer:model:0147", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0146", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00306", "@type": "RelationAssertion", "id": "R00306", "subject": "urn:business-engineer:model:0147", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: validated by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00307", "@type": "RelationAssertion", "id": "R00307", "subject": "urn:business-engineer:model:0147", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00308", "@type": "RelationAssertion", "id": "R00308", "subject": "urn:business-engineer:model:0148", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0054", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00309", "@type": "RelationAssertion", "id": "R00309", "subject": "urn:business-engineer:model:0148", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0136", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00310", "@type": "RelationAssertion", "id": "R00310", "subject": "urn:business-engineer:model:0148", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0140", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00311", "@type": "RelationAssertion", "id": "R00311", "subject": "urn:business-engineer:model:0148", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0143", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00312", "@type": "RelationAssertion", "id": "R00312", "subject": "urn:business-engineer:model:0149", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00313", "@type": "RelationAssertion", "id": "R00313", "subject": "urn:business-engineer:model:0149", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0136", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00314", "@type": "RelationAssertion", "id": "R00314", "subject": "urn:business-engineer:model:0149", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00315", "@type": "RelationAssertion", "id": "R00315", "subject": "urn:business-engineer:model:0149", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0159", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00316", "@type": "RelationAssertion", "id": "R00316", "subject": "urn:business-engineer:model:0150", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0031", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00317", "@type": "RelationAssertion", "id": "R00317", "subject": "urn:business-engineer:model:0150", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0035", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00318", "@type": "RelationAssertion", "id": "R00318", "subject": "urn:business-engineer:model:0150", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00319", "@type": "RelationAssertion", "id": "R00319", "subject": "urn:business-engineer:model:0150", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0161", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00320", "@type": "RelationAssertion", "id": "R00320", "subject": "urn:business-engineer:model:0151", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0030", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00321", "@type": "RelationAssertion", "id": "R00321", "subject": "urn:business-engineer:model:0151", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0097", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00322", "@type": "RelationAssertion", "id": "R00322", "subject": "urn:business-engineer:model:0151", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: depends on. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00323", "@type": "RelationAssertion", "id": "R00323", "subject": "urn:business-engineer:model:0152", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: qualified by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00324", "@type": "RelationAssertion", "id": "R00324", "subject": "urn:business-engineer:model:0152", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0045", "definition": "Prior catalog relation: refines. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00325", "@type": "RelationAssertion", "id": "R00325", "subject": "urn:business-engineer:model:0152", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0046", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00326", "@type": "RelationAssertion", "id": "R00326", "subject": "urn:business-engineer:model:0152", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0094", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00327", "@type": "RelationAssertion", "id": "R00327", "subject": "urn:business-engineer:model:0153", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0034", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00328", "@type": "RelationAssertion", "id": "R00328", "subject": "urn:business-engineer:model:0153", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0082", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00329", "@type": "RelationAssertion", "id": "R00329", "subject": "urn:business-engineer:model:0153", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0142", "definition": "Prior catalog relation: supports. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00330", "@type": "RelationAssertion", "id": "R00330", "subject": "urn:business-engineer:model:0153", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: supports. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00331", "@type": "RelationAssertion", "id": "R00331", "subject": "urn:business-engineer:model:0154", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0016", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00332", "@type": "RelationAssertion", "id": "R00332", "subject": "urn:business-engineer:model:0154", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0052", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00333", "@type": "RelationAssertion", "id": "R00333", "subject": "urn:business-engineer:model:0154", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0084", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00334", "@type": "RelationAssertion", "id": "R00334", "subject": "urn:business-engineer:model:0154", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00335", "@type": "RelationAssertion", "id": "R00335", "subject": "urn:business-engineer:model:0155", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0033", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00336", "@type": "RelationAssertion", "id": "R00336", "subject": "urn:business-engineer:model:0155", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0066", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00337", "@type": "RelationAssertion", "id": "R00337", "subject": "urn:business-engineer:model:0155", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0145", "definition": "Prior catalog relation: tested by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00338", "@type": "RelationAssertion", "id": "R00338", "subject": "urn:business-engineer:model:0155", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0157", "definition": "Prior catalog relation: measured by. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00339", "@type": "RelationAssertion", "id": "R00339", "subject": "urn:business-engineer:model:0156", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0035", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00340", "@type": "RelationAssertion", "id": "R00340", "subject": "urn:business-engineer:model:0156", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0085", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00341", "@type": "RelationAssertion", "id": "R00341", "subject": "urn:business-engineer:model:0156", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00342", "@type": "RelationAssertion", "id": "R00342", "subject": "urn:business-engineer:model:0157", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0066", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00343", "@type": "RelationAssertion", "id": "R00343", "subject": "urn:business-engineer:model:0157", "predicate": "urn:business-engineer:relation-type:analogousTo", "object": "urn:business-engineer:model:0115", "definition": "Prior catalog relation: analogous to. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00344", "@type": "RelationAssertion", "id": "R00344", "subject": "urn:business-engineer:model:0157", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0155", "definition": "Prior catalog relation: measures. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00345", "@type": "RelationAssertion", "id": "R00345", "subject": "urn:business-engineer:model:0157", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00346", "@type": "RelationAssertion", "id": "R00346", "subject": "urn:business-engineer:model:0158", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00347", "@type": "RelationAssertion", "id": "R00347", "subject": "urn:business-engineer:model:0158", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0013", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00348", "@type": "RelationAssertion", "id": "R00348", "subject": "urn:business-engineer:model:0158", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0084", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00349", "@type": "RelationAssertion", "id": "R00349", "subject": "urn:business-engineer:model:0158", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00350", "@type": "RelationAssertion", "id": "R00350", "subject": "urn:business-engineer:model:0159", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0014", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00351", "@type": "RelationAssertion", "id": "R00351", "subject": "urn:business-engineer:model:0159", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0047", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00352", "@type": "RelationAssertion", "id": "R00352", "subject": "urn:business-engineer:model:0159", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0149", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00353", "@type": "RelationAssertion", "id": "R00353", "subject": "urn:business-engineer:model:0159", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0151", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00354", "@type": "RelationAssertion", "id": "R00354", "subject": "urn:business-engineer:model:0160", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0037", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00355", "@type": "RelationAssertion", "id": "R00355", "subject": "urn:business-engineer:model:0160", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0085", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00356", "@type": "RelationAssertion", "id": "R00356", "subject": "urn:business-engineer:model:0160", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0147", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00357", "@type": "RelationAssertion", "id": "R00357", "subject": "urn:business-engineer:model:0160", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0156", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00358", "@type": "RelationAssertion", "id": "R00358", "subject": "urn:business-engineer:model:0161", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0035", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00359", "@type": "RelationAssertion", "id": "R00359", "subject": "urn:business-engineer:model:0161", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00360", "@type": "RelationAssertion", "id": "R00360", "subject": "urn:business-engineer:model:0161", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0150", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00361", "@type": "RelationAssertion", "id": "R00361", "subject": "urn:business-engineer:model:0161", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0155", "definition": "Prior catalog relation: measures. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00362", "@type": "RelationAssertion", "id": "R00362", "subject": "urn:business-engineer:model:0162", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0006", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00363", "@type": "RelationAssertion", "id": "R00363", "subject": "urn:business-engineer:model:0162", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0007", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00364", "@type": "RelationAssertion", "id": "R00364", "subject": "urn:business-engineer:model:0162", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0010", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00365", "@type": "RelationAssertion", "id": "R00365", "subject": "urn:business-engineer:model:0162", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: feeds. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00366", "@type": "RelationAssertion", "id": "R00366", "subject": "urn:business-engineer:model:0163", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0010", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00367", "@type": "RelationAssertion", "id": "R00367", "subject": "urn:business-engineer:model:0163", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0131", "definition": "Prior catalog relation: organizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00368", "@type": "RelationAssertion", "id": "R00368", "subject": "urn:business-engineer:model:0163", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0158", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00369", "@type": "RelationAssertion", "id": "R00369", "subject": "urn:business-engineer:model:0163", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0162", "definition": "Prior catalog relation: records. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00370", "@type": "RelationAssertion", "id": "R00370", "subject": "urn:business-engineer:model:0164", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0027", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00371", "@type": "RelationAssertion", "id": "R00371", "subject": "urn:business-engineer:model:0164", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0075", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00372", "@type": "RelationAssertion", "id": "R00372", "subject": "urn:business-engineer:model:0164", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0080", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00373", "@type": "RelationAssertion", "id": "R00373", "subject": "urn:business-engineer:model:0164", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00374", "@type": "RelationAssertion", "id": "R00374", "subject": "urn:business-engineer:model:0165", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0037", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00375", "@type": "RelationAssertion", "id": "R00375", "subject": "urn:business-engineer:model:0165", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0075", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00376", "@type": "RelationAssertion", "id": "R00376", "subject": "urn:business-engineer:model:0165", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0077", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00377", "@type": "RelationAssertion", "id": "R00377", "subject": "urn:business-engineer:model:0165", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0163", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00378", "@type": "RelationAssertion", "id": "R00378", "subject": "urn:business-engineer:model:0166", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0057", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00379", "@type": "RelationAssertion", "id": "R00379", "subject": "urn:business-engineer:model:0166", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0094", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00380", "@type": "RelationAssertion", "id": "R00380", "subject": "urn:business-engineer:model:0166", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0135", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00381", "@type": "RelationAssertion", "id": "R00381", "subject": "urn:business-engineer:model:0166", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0159", "definition": "Prior catalog relation: uses. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00382", "@type": "RelationAssertion", "id": "R00382", "subject": "urn:business-engineer:model:0167", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0008", "definition": "Prior catalog relation: disciplines. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00383", "@type": "RelationAssertion", "id": "R00383", "subject": "urn:business-engineer:model:0167", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0036", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00384", "@type": "RelationAssertion", "id": "R00384", "subject": "urn:business-engineer:model:0167", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0078", "definition": "Prior catalog relation: operationalizes. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00385", "@type": "RelationAssertion", "id": "R00385", "subject": "urn:business-engineer:model:0167", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0137", "definition": "Prior catalog relation: tests. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00386", "@type": "RelationAssertion", "id": "R00386", "subject": "urn:business-engineer:model:0168", "predicate": "urn:business-engineer:relation-type:relatedTo", "object": "urn:business-engineer:model:0015", "definition": "Prior catalog relation: applies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00387", "@type": "RelationAssertion", "id": "R00387", "subject": "urn:business-engineer:model:0168", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0082", "definition": "Prior catalog relation: qualifies. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00388", "@type": "RelationAssertion", "id": "R00388", "subject": "urn:business-engineer:model:0168", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0087", "definition": "Prior catalog relation: extends. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00389", "@type": "RelationAssertion", "id": "R00389", "subject": "urn:business-engineer:model:0168", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0153", "definition": "Prior catalog relation: complements. Interpret as a conceptual link; the label alone supplies no evidence.", "status": "Conceptual relation, not empirical causal proof", "origin": "Earlier reconciled catalog" }, { "@id": "urn:business-engineer:relation:00390", "@type": "RelationAssertion", "id": "R00390", "subject": "urn:business-engineer:model:0169", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0132", "definition": "Repricing Mechanisms extends Demand Has a Shape, Not Just a Size; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00391", "@type": "RelationAssertion", "id": "R00391", "subject": "urn:business-engineer:model:0169", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0122", "definition": "Repricing Mechanisms complements The Amplifier, Not the Bubble; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00392", "@type": "RelationAssertion", "id": "R00392", "subject": "urn:business-engineer:model:0170", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0131", "definition": "Political and Noncommercial Demand extends Asynchronous Clocks; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00393", "@type": "RelationAssertion", "id": "R00393", "subject": "urn:business-engineer:model:0170", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0139", "definition": "Political and Noncommercial Demand complements Legitimacy and Enforcement; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00394", "@type": "RelationAssertion", "id": "R00394", "subject": "urn:business-engineer:model:0171", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0016", "definition": "Geopolitical Junction Test specializes Power Distribution Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00395", "@type": "RelationAssertion", "id": "R00395", "subject": "urn:business-engineer:model:0171", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0139", "definition": "Geopolitical Junction Test complements Legitimacy and Enforcement; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00396", "@type": "RelationAssertion", "id": "R00396", "subject": "urn:business-engineer:model:0172", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0140", "definition": "Dependency Migration complements Strategic Dependence Asymmetry; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00397", "@type": "RelationAssertion", "id": "R00397", "subject": "urn:business-engineer:model:0172", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Dependency Migration complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00398", "@type": "RelationAssertion", "id": "R00398", "subject": "urn:business-engineer:model:0173", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0139", "definition": "Revocable Permission Layer specializes Legitimacy and Enforcement; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00399", "@type": "RelationAssertion", "id": "R00399", "subject": "urn:business-engineer:model:0173", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Revocable Permission Layer complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00400", "@type": "RelationAssertion", "id": "R00400", "subject": "urn:business-engineer:model:0174", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0139", "definition": "Control Coverage Gaps qualifies Legitimacy and Enforcement; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00401", "@type": "RelationAssertion", "id": "R00401", "subject": "urn:business-engineer:model:0175", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0091", "definition": "Noncommercial Capacity Entry extends Capital Asymmetry of AI; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00402", "@type": "RelationAssertion", "id": "R00402", "subject": "urn:business-engineer:model:0175", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0134", "definition": "Noncommercial Capacity Entry complements Efficiency, Demand and Value Incidence; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00403", "@type": "RelationAssertion", "id": "R00403", "subject": "urn:business-engineer:model:0176", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0090", "definition": "National Sector Concentration complements Market Structure Dynamics; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00404", "@type": "RelationAssertion", "id": "R00404", "subject": "urn:business-engineer:model:0176", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0127", "definition": "National Sector Concentration complements Downstream Incidence (The Bill for the Build); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00405", "@type": "RelationAssertion", "id": "R00405", "subject": "urn:business-engineer:model:0177", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0119", "definition": "Contracted Risk Transfer specializes Deferral vs Transfer; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00406", "@type": "RelationAssertion", "id": "R00406", "subject": "urn:business-engineer:model:0177", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0121", "definition": "Contracted Risk Transfer complements The Credit Floor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00407", "@type": "RelationAssertion", "id": "R00407", "subject": "urn:business-engineer:model:0178", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0125", "definition": "Payment Certainty and Capacity Adaptability complements The Sequencing Bet; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00408", "@type": "RelationAssertion", "id": "R00408", "subject": "urn:business-engineer:model:0178", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0128", "definition": "Payment Certainty and Capacity Adaptability complements Price Is Not Capacity; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00409", "@type": "RelationAssertion", "id": "R00409", "subject": "urn:business-engineer:model:0179", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0122", "definition": "Inflation and Financing Feedback complements The Amplifier, Not the Bubble; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00410", "@type": "RelationAssertion", "id": "R00410", "subject": "urn:business-engineer:model:0179", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0127", "definition": "Inflation and Financing Feedback complements Downstream Incidence (The Bill for the Build); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00411", "@type": "RelationAssertion", "id": "R00411", "subject": "urn:business-engineer:model:0180", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0090", "definition": "Merchant Market Compression specializes Market Structure Dynamics; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00412", "@type": "RelationAssertion", "id": "R00412", "subject": "urn:business-engineer:model:0181", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0137", "definition": "Production Scale and Interdiction Exposure complements Technology Constellation; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00413", "@type": "RelationAssertion", "id": "R00413", "subject": "urn:business-engineer:model:0181", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0139", "definition": "Production Scale and Interdiction Exposure complements Legitimacy and Enforcement; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00414", "@type": "RelationAssertion", "id": "R00414", "subject": "urn:business-engineer:model:0182", "predicate": "urn:business-engineer:relation-type:operationalizesModel", "object": "urn:business-engineer:model:0020", "definition": "Economic Seat Taxonomy operationalizesModel Perspective-First Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00415", "@type": "RelationAssertion", "id": "R00415", "subject": "urn:business-engineer:model:0182", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0127", "definition": "Economic Seat Taxonomy complements Downstream Incidence (The Bill for the Build); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00416", "@type": "RelationAssertion", "id": "R00416", "subject": "urn:business-engineer:model:0183", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0117", "definition": "Asset-Light Exposure qualifies Expensed vs Capitalized (The Control Group); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00417", "@type": "RelationAssertion", "id": "R00417", "subject": "urn:business-engineer:model:0183", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0136", "definition": "Asset-Light Exposure complements Clear Title (KEPT / PARTIAL / CAPTURED); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00418", "@type": "RelationAssertion", "id": "R00418", "subject": "urn:business-engineer:model:0184", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0112", "definition": "Local Proof and System Scale qualifies Capital Recovery Hurdle; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00419", "@type": "RelationAssertion", "id": "R00419", "subject": "urn:business-engineer:model:0184", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0132", "definition": "Local Proof and System Scale complements Demand Has a Shape, Not Just a Size; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00420", "@type": "RelationAssertion", "id": "R00420", "subject": "urn:business-engineer:model:0185", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0116", "definition": "Operating Performance and Valuation Duration complements Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00421", "@type": "RelationAssertion", "id": "R00421", "subject": "urn:business-engineer:model:0185", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0095", "definition": "Operating Performance and Valuation Duration complements Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00422", "@type": "RelationAssertion", "id": "R00422", "subject": "urn:business-engineer:model:0186", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0123", "definition": "Circular Commercial and Financial Exposure specializes The Layer Map Is Not the Credit Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00423", "@type": "RelationAssertion", "id": "R00423", "subject": "urn:business-engineer:model:0186", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0116", "definition": "Circular Commercial and Financial Exposure complements Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00424", "@type": "RelationAssertion", "id": "R00424", "subject": "urn:business-engineer:model:0187", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0073", "definition": "Leveraged Equity Funding qualifies Asymmetric Betting Matrix; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00425", "@type": "RelationAssertion", "id": "R00425", "subject": "urn:business-engineer:model:0187", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0122", "definition": "Leveraged Equity Funding complements The Amplifier, Not the Bubble; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00426", "@type": "RelationAssertion", "id": "R00426", "subject": "urn:business-engineer:model:0188", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0116", "definition": "Valuation Update Lag complements Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00427", "@type": "RelationAssertion", "id": "R00427", "subject": "urn:business-engineer:model:0189", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0115", "definition": "Customer-Funded Working Capital complements Operating Absorption ≠ Cash Absorption; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00428", "@type": "RelationAssertion", "id": "R00428", "subject": "urn:business-engineer:model:0189", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0119", "definition": "Customer-Funded Working Capital complements Deferral vs Transfer; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00429", "@type": "RelationAssertion", "id": "R00429", "subject": "urn:business-engineer:model:0190", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0115", "definition": "Integrator Working Capital Exposure specializes Operating Absorption ≠ Cash Absorption; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00430", "@type": "RelationAssertion", "id": "R00430", "subject": "urn:business-engineer:model:0191", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0038", "definition": "Scarcity Rent and Structural Rent qualifies Moat Hierarchy (Level 1/2/3); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00431", "@type": "RelationAssertion", "id": "R00431", "subject": "urn:business-engineer:model:0191", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0129", "definition": "Scarcity Rent and Structural Rent complements Toll Booths vs Tourists; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00432", "@type": "RelationAssertion", "id": "R00432", "subject": "urn:business-engineer:model:0192", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0116", "definition": "Customer Equity Incentives complements Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00433", "@type": "RelationAssertion", "id": "R00433", "subject": "urn:business-engineer:model:0192", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0159", "definition": "Customer Equity Incentives complements Incentive Compatibility Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00434", "@type": "RelationAssertion", "id": "R00434", "subject": "urn:business-engineer:model:0193", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0066", "definition": "Group Value-Source Migration complements VTDF Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00435", "@type": "RelationAssertion", "id": "R00435", "subject": "urn:business-engineer:model:0193", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0095", "definition": "Group Value-Source Migration complements Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00436", "@type": "RelationAssertion", "id": "R00436", "subject": "urn:business-engineer:model:0194", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0121", "definition": "Credit-Supported Asset Financing specializes The Credit Floor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00437", "@type": "RelationAssertion", "id": "R00437", "subject": "urn:business-engineer:model:0194", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0125", "definition": "Credit-Supported Asset Financing complements The Sequencing Bet; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00438", "@type": "RelationAssertion", "id": "R00438", "subject": "urn:business-engineer:model:0195", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0132", "definition": "Merchant and Captive Measurement Boundary qualifies Demand Has a Shape, Not Just a Size; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00439", "@type": "RelationAssertion", "id": "R00439", "subject": "urn:business-engineer:model:0195", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0111", "definition": "Merchant and Captive Measurement Boundary complements Operating Absorption and Capital Intensity; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00440", "@type": "RelationAssertion", "id": "R00440", "subject": "urn:business-engineer:model:0196", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "AI Cost Incidence in Software complements Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00441", "@type": "RelationAssertion", "id": "R00441", "subject": "urn:business-engineer:model:0196", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0047", "definition": "AI Cost Incidence in Software complements Margin Conflict Strategy; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00442", "@type": "RelationAssertion", "id": "R00442", "subject": "urn:business-engineer:model:0197", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0099", "definition": "Discovery Channel Erosion specializes AI Search Paradigm Shift; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00443", "@type": "RelationAssertion", "id": "R00443", "subject": "urn:business-engineer:model:0197", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0097", "definition": "Discovery Channel Erosion complements Digital Distribution Layers; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00444", "@type": "RelationAssertion", "id": "R00444", "subject": "urn:business-engineer:model:0198", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0146", "definition": "Information Substitution and Transaction Completion complements Semantic-to-Action Ladder; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00445", "@type": "RelationAssertion", "id": "R00445", "subject": "urn:business-engineer:model:0198", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Information Substitution and Transaction Completion complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00446", "@type": "RelationAssertion", "id": "R00446", "subject": "urn:business-engineer:model:0199", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0129", "definition": "Machine-Access Monetization specializes Toll Booths vs Tourists; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00447", "@type": "RelationAssertion", "id": "R00447", "subject": "urn:business-engineer:model:0199", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Machine-Access Monetization complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00448", "@type": "RelationAssertion", "id": "R00448", "subject": "urn:business-engineer:model:0200", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0097", "definition": "Interface-to-Substrate Transition extends Digital Distribution Layers; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00449", "@type": "RelationAssertion", "id": "R00449", "subject": "urn:business-engineer:model:0200", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Interface-to-Substrate Transition complements Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00450", "@type": "RelationAssertion", "id": "R00450", "subject": "urn:business-engineer:model:0201", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0046", "definition": "Segment-Level Substitution complements Weak Spot Analysis (5 Attack Vectors); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00451", "@type": "RelationAssertion", "id": "R00451", "subject": "urn:business-engineer:model:0201", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0031", "definition": "Segment-Level Substitution complements Niche-to-Microniche Strategy; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00452", "@type": "RelationAssertion", "id": "R00452", "subject": "urn:business-engineer:model:0202", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0010", "definition": "Metric Definition Drift complements Calibration Loop; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00453", "@type": "RelationAssertion", "id": "R00453", "subject": "urn:business-engineer:model:0202", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0163", "definition": "Metric Definition Drift complements Assumption and Prediction Ledger; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00454", "@type": "RelationAssertion", "id": "R00454", "subject": "urn:business-engineer:model:0203", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0116", "definition": "Earnings per Share Attribution extends Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00455", "@type": "RelationAssertion", "id": "R00455", "subject": "urn:business-engineer:model:0204", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0030", "definition": "Free-Tier Unit Economics complements Minimum Viable Audience (MVA); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00456", "@type": "RelationAssertion", "id": "R00456", "subject": "urn:business-engineer:model:0204", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Free-Tier Unit Economics complements Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00457", "@type": "RelationAssertion", "id": "R00457", "subject": "urn:business-engineer:model:0205", "predicate": "urn:business-engineer:relation-type:operationalizesModel", "object": "urn:business-engineer:model:0066", "definition": "Revenue Architecture Comparison operationalizesModel VTDF Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00458", "@type": "RelationAssertion", "id": "R00458", "subject": "urn:business-engineer:model:0206", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Information Inputs and Value Appropriation complements Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00459", "@type": "RelationAssertion", "id": "R00459", "subject": "urn:business-engineer:model:0206", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0060", "definition": "Information Inputs and Value Appropriation complements Data Flywheel; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00460", "@type": "RelationAssertion", "id": "R00460", "subject": "urn:business-engineer:model:0260", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0060", "definition": "Decision Residue Flywheel specializes Data Flywheel; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00461", "@type": "RelationAssertion", "id": "R00461", "subject": "urn:business-engineer:model:0260", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0144", "definition": "Decision Residue Flywheel complements Reference Library and Customer Delta; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00462", "@type": "RelationAssertion", "id": "R00462", "subject": "urn:business-engineer:model:0207", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Multi-Axis Routing complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00463", "@type": "RelationAssertion", "id": "R00463", "subject": "urn:business-engineer:model:0207", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Multi-Axis Routing complements Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00464", "@type": "RelationAssertion", "id": "R00464", "subject": "urn:business-engineer:model:0207", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Multi-Axis Routing complements Autonomy Envelope; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00465", "@type": "RelationAssertion", "id": "R00465", "subject": "urn:business-engineer:model:0208", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0167", "definition": "Routing Across Scales specializes Mechanism Transfer Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00466", "@type": "RelationAssertion", "id": "R00466", "subject": "urn:business-engineer:model:0209", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0053", "definition": "Model, Harness and Context Fit complements Context Engineering; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00467", "@type": "RelationAssertion", "id": "R00467", "subject": "urn:business-engineer:model:0209", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Model, Harness and Context Fit complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00468", "@type": "RelationAssertion", "id": "R00468", "subject": "urn:business-engineer:model:0210", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0143", "definition": "Cross-Depth Artifact Reuse extends Process Specification and Runtime; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00469", "@type": "RelationAssertion", "id": "R00469", "subject": "urn:business-engineer:model:0210", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0144", "definition": "Cross-Depth Artifact Reuse complements Reference Library and Customer Delta; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00470", "@type": "RelationAssertion", "id": "R00470", "subject": "urn:business-engineer:model:0211", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0054", "definition": "Selective Openness complements Protocol Mastery; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00471", "@type": "RelationAssertion", "id": "R00471", "subject": "urn:business-engineer:model:0211", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Selective Openness complements Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00472", "@type": "RelationAssertion", "id": "R00472", "subject": "urn:business-engineer:model:0212", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0046", "definition": "Capability Absorption Risk specializes Weak Spot Analysis (5 Attack Vectors); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00473", "@type": "RelationAssertion", "id": "R00473", "subject": "urn:business-engineer:model:0212", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0039", "definition": "Capability Absorption Risk qualifies Five Defensible Moats in AI; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00474", "@type": "RelationAssertion", "id": "R00474", "subject": "urn:business-engineer:model:0213", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0042", "definition": "Compute Stage and Workload Economics extends Three Layers of AI Industry; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00475", "@type": "RelationAssertion", "id": "R00475", "subject": "urn:business-engineer:model:0213", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Compute Stage and Workload Economics complements The Rotating Bottleneck; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00476", "@type": "RelationAssertion", "id": "R00476", "subject": "urn:business-engineer:model:0214", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0086", "definition": "Commercial and Capability Workload Allocation specializes Dual-Engine Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00477", "@type": "RelationAssertion", "id": "R00477", "subject": "urn:business-engineer:model:0215", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0130", "definition": "Architecture Specialization Signal complements The Rotating Bottleneck; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00478", "@type": "RelationAssertion", "id": "R00478", "subject": "urn:business-engineer:model:0215", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0164", "definition": "Architecture Specialization Signal complements Regime-Switch Trigger; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00479", "@type": "RelationAssertion", "id": "R00479", "subject": "urn:business-engineer:model:0216", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0082", "definition": "Iteration Access and Talent Retention complements Super Individual Contributor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00480", "@type": "RelationAssertion", "id": "R00480", "subject": "urn:business-engineer:model:0217", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0142", "definition": "Semantic Index Control complements Computable Operating Model; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00481", "@type": "RelationAssertion", "id": "R00481", "subject": "urn:business-engineer:model:0217", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Semantic Index Control complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00482", "@type": "RelationAssertion", "id": "R00482", "subject": "urn:business-engineer:model:0218", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0143", "definition": "Four-Plane Intelligence Architecture complements Process Specification and Runtime; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00483", "@type": "RelationAssertion", "id": "R00483", "subject": "urn:business-engineer:model:0218", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Four-Plane Intelligence Architecture complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00484", "@type": "RelationAssertion", "id": "R00484", "subject": "urn:business-engineer:model:0219", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0053", "definition": "Context and Delegation Trust Boundaries qualifies Context Engineering; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00485", "@type": "RelationAssertion", "id": "R00485", "subject": "urn:business-engineer:model:0219", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Context and Delegation Trust Boundaries complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00486", "@type": "RelationAssertion", "id": "R00486", "subject": "urn:business-engineer:model:0219", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Context and Delegation Trust Boundaries complements Autonomy Envelope; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00487", "@type": "RelationAssertion", "id": "R00487", "subject": "urn:business-engineer:model:0220", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0146", "definition": "Query and Vocabulary Fit complements Semantic-to-Action Ladder; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00488", "@type": "RelationAssertion", "id": "R00488", "subject": "urn:business-engineer:model:0220", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0147", "definition": "Query and Vocabulary Fit complements Action Boundary Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00489", "@type": "RelationAssertion", "id": "R00489", "subject": "urn:business-engineer:model:0221", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0010", "definition": "Metric Optimization Pressure complements Calibration Loop; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00490", "@type": "RelationAssertion", "id": "R00490", "subject": "urn:business-engineer:model:0221", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0162", "definition": "Metric Optimization Pressure complements Counter-Model Pairing; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00491", "@type": "RelationAssertion", "id": "R00491", "subject": "urn:business-engineer:model:0222", "predicate": "urn:business-engineer:relation-type:operationalizesModel", "object": "urn:business-engineer:model:0149", "definition": "Independent Evaluation Standard operationalizesModel Governance Independence Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00492", "@type": "RelationAssertion", "id": "R00492", "subject": "urn:business-engineer:model:0222", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Independent Evaluation Standard complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00493", "@type": "RelationAssertion", "id": "R00493", "subject": "urn:business-engineer:model:0223", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0143", "definition": "Behavioral Acceptance Specification complements Process Specification and Runtime; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00494", "@type": "RelationAssertion", "id": "R00494", "subject": "urn:business-engineer:model:0223", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Behavioral Acceptance Specification complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00495", "@type": "RelationAssertion", "id": "R00495", "subject": "urn:business-engineer:model:0224", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0143", "definition": "Governed Decision Loop extends Process Specification and Runtime; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00496", "@type": "RelationAssertion", "id": "R00496", "subject": "urn:business-engineer:model:0224", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Governed Decision Loop complements Autonomy Envelope; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00497", "@type": "RelationAssertion", "id": "R00497", "subject": "urn:business-engineer:model:0225", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Engineered Unit Economics complements Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00498", "@type": "RelationAssertion", "id": "R00498", "subject": "urn:business-engineer:model:0225", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0161", "definition": "Engineered Unit Economics qualifies Maintenance Burden Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00499", "@type": "RelationAssertion", "id": "R00499", "subject": "urn:business-engineer:model:0226", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0157", "definition": "Usage-Tail Pricing qualifies Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00500", "@type": "RelationAssertion", "id": "R00500", "subject": "urn:business-engineer:model:0227", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0066", "definition": "Hybrid Pricing Transition specializes VTDF Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00501", "@type": "RelationAssertion", "id": "R00501", "subject": "urn:business-engineer:model:0227", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0159", "definition": "Hybrid Pricing Transition complements Incentive Compatibility Map; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00502", "@type": "RelationAssertion", "id": "R00502", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0095", "definition": "Valuation Assumption Audit extends Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00503", "@type": "RelationAssertion", "id": "R00503", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0112", "definition": "Valuation Assumption Audit complements Capital Recovery Hurdle; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00504", "@type": "RelationAssertion", "id": "R00504", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0162", "definition": "Valuation Assumption Audit complements Counter-Model Pairing; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00505", "@type": "RelationAssertion", "id": "R00505", "subject": "urn:business-engineer:model:0229", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0111", "definition": "Revenue Counting Boundary qualifies Operating Absorption and Capital Intensity; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00506", "@type": "RelationAssertion", "id": "R00506", "subject": "urn:business-engineer:model:0229", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0116", "definition": "Revenue Counting Boundary complements Operating and Non-Operating Earnings; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00507", "@type": "RelationAssertion", "id": "R00507", "subject": "urn:business-engineer:model:0230", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0135", "definition": "Durable and Perishable Value complements Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00508", "@type": "RelationAssertion", "id": "R00508", "subject": "urn:business-engineer:model:0230", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0095", "definition": "Durable and Perishable Value complements Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00509", "@type": "RelationAssertion", "id": "R00509", "subject": "urn:business-engineer:model:0231", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0095", "definition": "Enterprise Value and Obligation Reconciliation complements Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00510", "@type": "RelationAssertion", "id": "R00510", "subject": "urn:business-engineer:model:0231", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0119", "definition": "Enterprise Value and Obligation Reconciliation complements Deferral vs Transfer; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00511", "@type": "RelationAssertion", "id": "R00511", "subject": "urn:business-engineer:model:0232", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0041", "definition": "Failure Scenario Valuation specializes The Survival Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00512", "@type": "RelationAssertion", "id": "R00512", "subject": "urn:business-engineer:model:0232", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0073", "definition": "Failure Scenario Valuation complements Asymmetric Betting Matrix; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00513", "@type": "RelationAssertion", "id": "R00513", "subject": "urn:business-engineer:model:0233", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0095", "definition": "Transaction Perimeter Read qualifies Comparable Company Analysis; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00514", "@type": "RelationAssertion", "id": "R00514", "subject": "urn:business-engineer:model:0234", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0094", "definition": "Buyer and Seller Repetition Asymmetry specializes Negotiation Leverage Matrix; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00515", "@type": "RelationAssertion", "id": "R00515", "subject": "urn:business-engineer:model:0234", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0154", "definition": "Buyer and Seller Repetition Asymmetry complements Buyer Permission Path; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00516", "@type": "RelationAssertion", "id": "R00516", "subject": "urn:business-engineer:model:0235", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0154", "definition": "Buyer Qualification Framework extends Buyer Permission Path; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00517", "@type": "RelationAssertion", "id": "R00517", "subject": "urn:business-engineer:model:0235", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0136", "definition": "Buyer Qualification Framework complements Clear Title (KEPT / PARTIAL / CAPTURED); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00518", "@type": "RelationAssertion", "id": "R00518", "subject": "urn:business-engineer:model:0236", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0149", "definition": "Evaluation Provenance and Buyer Control complements Governance Independence Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00519", "@type": "RelationAssertion", "id": "R00519", "subject": "urn:business-engineer:model:0236", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Evaluation Provenance and Buyer Control complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00520", "@type": "RelationAssertion", "id": "R00520", "subject": "urn:business-engineer:model:0237", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0154", "definition": "Governed Fast Intake complements Buyer Permission Path; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00521", "@type": "RelationAssertion", "id": "R00521", "subject": "urn:business-engineer:model:0237", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0160", "definition": "Governed Fast Intake complements Autonomy Envelope; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00522", "@type": "RelationAssertion", "id": "R00522", "subject": "urn:business-engineer:model:0238", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0135", "definition": "Deployment Control Inheritance specializes Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00523", "@type": "RelationAssertion", "id": "R00523", "subject": "urn:business-engineer:model:0238", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Deployment Control Inheritance complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00524", "@type": "RelationAssertion", "id": "R00524", "subject": "urn:business-engineer:model:0239", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0152", "definition": "Subsidy and Substitution Timing complements Coopetition Boundary; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00525", "@type": "RelationAssertion", "id": "R00525", "subject": "urn:business-engineer:model:0239", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Subsidy and Substitution Timing complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00526", "@type": "RelationAssertion", "id": "R00526", "subject": "urn:business-engineer:model:0240", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0155", "definition": "Portability-Aligned Delivery complements Product-to-Service Boundary; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00527", "@type": "RelationAssertion", "id": "R00527", "subject": "urn:business-engineer:model:0240", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Portability-Aligned Delivery complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00528", "@type": "RelationAssertion", "id": "R00528", "subject": "urn:business-engineer:model:0241", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0136", "definition": "Layered Dependency Audit extends Clear Title (KEPT / PARTIAL / CAPTURED); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00529", "@type": "RelationAssertion", "id": "R00529", "subject": "urn:business-engineer:model:0241", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0148", "definition": "Layered Dependency Audit complements Portability Is Exercised; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00530", "@type": "RelationAssertion", "id": "R00530", "subject": "urn:business-engineer:model:0242", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0151", "definition": "Enterprise as Distribution Complement complements Partner Distribution Fit; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00531", "@type": "RelationAssertion", "id": "R00531", "subject": "urn:business-engineer:model:0242", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0140", "definition": "Enterprise as Distribution Complement complements Strategic Dependence Asymmetry; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00532", "@type": "RelationAssertion", "id": "R00532", "subject": "urn:business-engineer:model:0243", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0087", "definition": "Relative Productivity Advantage qualifies Productivity Spectrum; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00533", "@type": "RelationAssertion", "id": "R00533", "subject": "urn:business-engineer:model:0244", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0087", "definition": "Productivity Transmission Across Scales extends Productivity Spectrum; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00534", "@type": "RelationAssertion", "id": "R00534", "subject": "urn:business-engineer:model:0244", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0168", "definition": "Productivity Transmission Across Scales complements Coordination Tax; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00535", "@type": "RelationAssertion", "id": "R00535", "subject": "urn:business-engineer:model:0245", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0083", "definition": "Federated Discovery and Central Coordination complements Permanent Beta Organization; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00536", "@type": "RelationAssertion", "id": "R00536", "subject": "urn:business-engineer:model:0245", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0168", "definition": "Federated Discovery and Central Coordination complements Coordination Tax; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00537", "@type": "RelationAssertion", "id": "R00537", "subject": "urn:business-engineer:model:0246", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0072", "definition": "Complementary Organizational Change complements AI Implementation Pyramid (4-Tier); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00538", "@type": "RelationAssertion", "id": "R00538", "subject": "urn:business-engineer:model:0246", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0084", "definition": "Complementary Organizational Change complements FRED Readiness Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00539", "@type": "RelationAssertion", "id": "R00539", "subject": "urn:business-engineer:model:0247", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0082", "definition": "Task Automation and Augmentation qualifies Super Individual Contributor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00540", "@type": "RelationAssertion", "id": "R00540", "subject": "urn:business-engineer:model:0247", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0085", "definition": "Task Automation and Augmentation complements AI Discernment Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00541", "@type": "RelationAssertion", "id": "R00541", "subject": "urn:business-engineer:model:0248", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0082", "definition": "Human and Agent Capacity Envelope qualifies Super Individual Contributor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00542", "@type": "RelationAssertion", "id": "R00542", "subject": "urn:business-engineer:model:0248", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Human and Agent Capacity Envelope complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00543", "@type": "RelationAssertion", "id": "R00543", "subject": "urn:business-engineer:model:0249", "predicate": "urn:business-engineer:relation-type:specializes", "object": "urn:business-engineer:model:0038", "definition": "Organizational Complementarity Moat specializes Moat Hierarchy (Level 1/2/3); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00544", "@type": "RelationAssertion", "id": "R00544", "subject": "urn:business-engineer:model:0249", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0040", "definition": "Organizational Complementarity Moat complements Compound Moat Strategy; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00545", "@type": "RelationAssertion", "id": "R00545", "subject": "urn:business-engineer:model:0250", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0085", "definition": "Apprenticeship Erosion and Redesign complements AI Discernment Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00546", "@type": "RelationAssertion", "id": "R00546", "subject": "urn:business-engineer:model:0250", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0083", "definition": "Apprenticeship Erosion and Redesign complements Permanent Beta Organization; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00547", "@type": "RelationAssertion", "id": "R00547", "subject": "urn:business-engineer:model:0251", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0085", "definition": "Exception Judgment and Standard Evolution extends AI Discernment Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00548", "@type": "RelationAssertion", "id": "R00548", "subject": "urn:business-engineer:model:0251", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0144", "definition": "Exception Judgment and Standard Evolution complements Reference Library and Customer Delta; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00549", "@type": "RelationAssertion", "id": "R00549", "subject": "urn:business-engineer:model:0252", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0144", "definition": "Expert Seeding Investment complements Reference Library and Customer Delta; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00550", "@type": "RelationAssertion", "id": "R00550", "subject": "urn:business-engineer:model:0252", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0156", "definition": "Expert Seeding Investment complements Reliability Budget; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00551", "@type": "RelationAssertion", "id": "R00551", "subject": "urn:business-engineer:model:0253", "predicate": "urn:business-engineer:relation-type:extends", "object": "urn:business-engineer:model:0082", "definition": "Expert Leverage Economics extends Super Individual Contributor; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00552", "@type": "RelationAssertion", "id": "R00552", "subject": "urn:business-engineer:model:0253", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0157", "definition": "Expert Leverage Economics complements Cost per Accepted Outcome; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00553", "@type": "RelationAssertion", "id": "R00553", "subject": "urn:business-engineer:model:0254", "predicate": "urn:business-engineer:relation-type:operationalizesModel", "object": "urn:business-engineer:model:0135", "definition": "Four Ownerships of AI Work operationalizesModel Own the Junctions, Rent the Ends (The Property Line); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00554", "@type": "RelationAssertion", "id": "R00554", "subject": "urn:business-engineer:model:0254", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0149", "definition": "Four Ownerships of AI Work complements Governance Independence Test; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00555", "@type": "RelationAssertion", "id": "R00555", "subject": "urn:business-engineer:model:0255", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0153", "definition": "Executive Role Reconfiguration complements Deployment Responsibility Coverage; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00556", "@type": "RelationAssertion", "id": "R00556", "subject": "urn:business-engineer:model:0255", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0081", "definition": "Executive Role Reconfiguration complements AI-Native Organizational Archetypes; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00557", "@type": "RelationAssertion", "id": "R00557", "subject": "urn:business-engineer:model:0256", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0145", "definition": "Deployment Decision Sequence complements N+1 Deployment Learning Curve; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00558", "@type": "RelationAssertion", "id": "R00558", "subject": "urn:business-engineer:model:0256", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0153", "definition": "Deployment Decision Sequence complements Deployment Responsibility Coverage; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00559", "@type": "RelationAssertion", "id": "R00559", "subject": "urn:business-engineer:model:0256", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0158", "definition": "Deployment Decision Sequence complements Evidence-to-Value Chain; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00560", "@type": "RelationAssertion", "id": "R00560", "subject": "urn:business-engineer:model:0257", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0097", "definition": "Intent-Based Monetization complements Digital Distribution Layers; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00561", "@type": "RelationAssertion", "id": "R00561", "subject": "urn:business-engineer:model:0257", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0066", "definition": "Intent-Based Monetization complements VTDF Framework; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00562", "@type": "RelationAssertion", "id": "R00562", "subject": "urn:business-engineer:model:0258", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0056", "definition": "Transformation Direction qualifies AI-Up (AI-Native Startup); apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00563", "@type": "RelationAssertion", "id": "R00563", "subject": "urn:business-engineer:model:0258", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0068", "definition": "Transformation Direction complements Transitional vs Foundational Technology; apply the narrower evidence and boundary conditions.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00564", "@type": "RelationAssertion", "id": "R00564", "subject": "urn:business-engineer:model:0222", "predicate": "urn:business-engineer:relation-type:qualifies", "object": "urn:business-engineer:model:0221", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00565", "@type": "RelationAssertion", "id": "R00565", "subject": "urn:business-engineer:model:0236", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0222", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00566", "@type": "RelationAssertion", "id": "R00566", "subject": "urn:business-engineer:model:0224", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0222", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00567", "@type": "RelationAssertion", "id": "R00567", "subject": "urn:business-engineer:model:0224", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0260", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00568", "@type": "RelationAssertion", "id": "R00568", "subject": "urn:business-engineer:model:0259", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0218", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00569", "@type": "RelationAssertion", "id": "R00569", "subject": "urn:business-engineer:model:0212", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0230", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00570", "@type": "RelationAssertion", "id": "R00570", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0229", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00571", "@type": "RelationAssertion", "id": "R00571", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0231", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00572", "@type": "RelationAssertion", "id": "R00572", "subject": "urn:business-engineer:model:0228", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0232", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00573", "@type": "RelationAssertion", "id": "R00573", "subject": "urn:business-engineer:model:0235", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0236", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00574", "@type": "RelationAssertion", "id": "R00574", "subject": "urn:business-engineer:model:0235", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0254", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00575", "@type": "RelationAssertion", "id": "R00575", "subject": "urn:business-engineer:model:0256", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0223", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00576", "@type": "RelationAssertion", "id": "R00576", "subject": "urn:business-engineer:model:0256", "predicate": "urn:business-engineer:relation-type:usesModel", "object": "urn:business-engineer:model:0224", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00577", "@type": "RelationAssertion", "id": "R00577", "subject": "urn:business-engineer:model:0244", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0245", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00578", "@type": "RelationAssertion", "id": "R00578", "subject": "urn:business-engineer:model:0248", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0222", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00579", "@type": "RelationAssertion", "id": "R00579", "subject": "urn:business-engineer:model:0253", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0251", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00580", "@type": "RelationAssertion", "id": "R00580", "subject": "urn:business-engineer:model:0177", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0194", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00581", "@type": "RelationAssertion", "id": "R00581", "subject": "urn:business-engineer:model:0180", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0195", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation:00582", "@type": "RelationAssertion", "id": "R00582", "subject": "urn:business-engineer:model:0191", "predicate": "urn:business-engineer:relation-type:complements", "object": "urn:business-engineer:model:0212", "definition": "Explicit cross-pack mechanism connection; test the relationship in the case at hand.", "status": "Conceptual relation, not empirical causal proof", "origin": "Reconciliation proposal" }, { "@id": "urn:business-engineer:relation-type:complements", "@type": "RelationType", "id": "complements", "name": "complements", "definition": "Two mechanisms illuminate different parts of a case. Store one assertion; inspection traverses both directions.", "directionality": "symmetrical" }, { "@id": "urn:business-engineer:relation-type:extends", "@type": "RelationType", "id": "extends", "name": "extends", "definition": "Adds a dimension to another mechanism without claiming logical subsumption.", "directionality": "directed" }, { "@id": "urn:business-engineer:relation-type:specializes", "@type": "RelationType", "id": "specializes", "name": "specializes", "definition": "Narrows a mechanism to a stated context; no automatic causal or truth inheritance.", "directionality": "directed-acyclic" }, { "@id": "urn:business-engineer:relation-type:qualifies", "@type": "RelationType", "id": "qualifies", "name": "qualifies", "definition": "Limits an inference that might otherwise be drawn from the target.", "directionality": "directed" }, { "@id": "urn:business-engineer:relation-type:analogousTo", "@type": "RelationType", "id": "analogousTo", "name": "analogousTo", "definition": "A proposed structural analogy requiring an import test.", "directionality": "symmetrical" }, { "@id": "urn:business-engineer:relation-type:relatedTo", "@type": "RelationType", "id": "relatedTo", "name": "relatedTo", "definition": "A useful conceptual connection without a more precise supported relation.", "directionality": "undetermined" }, { "@id": "urn:business-engineer:relation-type:usesModel", "@type": "RelationType", "id": "usesModel", "name": "usesModel", "definition": "A framework calls for applying another model.", "directionality": "directed" }, { "@id": "urn:business-engineer:relation-type:operationalizesModel", "@type": "RelationType", "id": "operationalizesModel", "name": "operationalizesModel", "definition": "A model-form framework turns a broader principle into an explicit diagnostic; distinct from an Instrument operationalizes edge.", "directionality": "directed" } ] }