Concept

A perceived regularity or pattern that can be named.

Schema

required:
  name:
    cardinality: exactly 1
    description: The concept's canonical name
    example: "Dissipative Structure"
  definition:
    cardinality: exactly 1
    description: >
      One-liner glossary entry. Must be atomic: no name-dropping other
      concepts. A reader with zero prior knowledge should understand
      this definition without needing to look up any other node in the graph.
      If the definition requires another concept, that dependency belongs
      in a relationship (requires_understanding), not in the text.
    example: "A persistent pattern sustained by energy passing through it"

recommended:
  purpose:
    type: text
    description: What function does it serve?
    example: "Explains how spontaneous order arises far from equilibrium"
  solves:
    type: text
    description: What problem question does it address?
    example: "How can structured, patterned systems exist in a universe trending toward disorder?"
  without:
    type: text
    description: What breaks without it?
    example: "No explanation for hurricanes, flames, or life — just equilibrium and chaos"

suggested:
  epistemicStatus:
    type: enum
    values: [refuted, corroborated]
    description: Epistemic status. If refuted, by what?
    example: "corroborated"
  measurement_approach:
    type: enum
    values: [direct, proxy, elicited, self_report]
    applies_to: Metric
    description: >
      How this concept is measured. Direct = timestamp/count.
      Proxy = correlated observable. Elicited = structured human judgment.
      Self_report = agent self-assessment.
    example: "direct"
  what_it_misses:
    type: text
    applies_to: Metric
    description: >
      What aspect of the measured concept this metric fails to capture.
      This is where Goodhart's Law will attack. Forces explicit
      acknowledgment of the gap between metric and reality.
    example: "Whether detection was accidental or systematic"

relationships:
  required:
    subsumed_under:
      range: Concept
      transitive: true
      description: >
        Ausubel subsumption (derivative, correlative, superordinate).
        A -subsumed_under-> B means A is understood through B. B is the
        more inclusive anchoring concept. Covers both "A is a case of B"
        (derivative) and "A extends/modifies B" (correlative).
        Arrow points upward to parent. Root concepts have no outgoing
        subsumed_under edges. Transitive: do not encode transitive edges
        — only direct parent.
      example: "Hurricane -subsumed_under-> Dissipative Structure"
    <phrase>:
      range: Concept
      description: >
        Novak linking phrase. The relationship type IS the phrase itself
        (e.g. REQUIRES, RESISTS, MAINTAINS, ENABLES, IS_NOT).
        Must read as a sentence: A [phrase] B. Every concept must have
        at least one phrase edge connecting it to another concept.
        This is the natural language layer of the graph.
        Do not create inverse relationships (e.g. MEASURES and MEASURED_BY).
        Commit to one direction. The inverse is implicit by traversing
        the edge backwards.
      example: "Steady State -IS_NOT-> Equilibrium"
  recommended:
    necessary_for:
      range: Concept
      transitive: true
      description: >
        A -necessary_for-> B means if A doesn't hold, B can't hold.
        A is a condition for B, not a type of B. Distinct from subsumes:
        subsumes = "A is a case of B", necessary_for = "A is required for B."
        Transitive: do not encode transitive edges — only direct dependency.
      example: "Fast Error Detection -necessary_for-> Update Quality"
    requires_understanding:
      range: Concept
      description: >
        A -requires_understanding-> B means to understand A, you must
        first understand B. The arrow points to what needs to be known.
        Distinct from subsumes: A is not a case of B.
      example: "Dissipative Structure -requires_understanding-> Energy Flow"
    originated_from:
      range: Person
      edge_properties:
        year: integer
      description: >
        Who created, discovered, or formalized this concept.
      example: "Dissipative Structure -originated_from {year: 1967}-> Ilya Prigogine"

Concept

The core knowledge unit in the PKM system. Represents ideas, theories, principles, methods.

Schema

required:
  definition:
    cardinality: exactly 1
    description: One-liner glossary entry

suggested:
  purpose:
    type: text
    description: What function does it serve?
  solves:
    type: text
    description: What problem does it address?
  without:
    type: text
    description: What breaks without it?
  epistemicStatus:
    type: enum
    values: [conjecture, refuted, corroborated]
    description: Epistemic status to this date. if refuted, by what ? what is now the corroborated theory instead

relationships:
  belongsTo:
    range: Domain
    description: Knowledge domain membership
  enables:
    range: Concept
    edge_properties:
      strength: float
    description: What this concept makes possible
  presupposes:
    range: Concept
    edge_properties:
      necessity: enum[logical, practical, historical]
    description: What must exist for this to make sense
  refutes:
    range: Concept
    edge_properties:
      strength: float
      mechanism: string
    description: What this undermines/attacks
  contradicts:
    range: Concept
    symmetric: true
    description: Logically incompatible concepts
  opposite:
    range: Concept
    edge_properties:
      dimension: string
    symmetric: true
    description: Conceptual polarity along an axis
  travelsWith:
    range: Concept
    symmetric: true
    description: Co-occurs without causal claim
  childOf:
    range: Concept
    description: Taxonomic parent (narrower term)
  instanceOf:
    range: Concept
    description: Concrete example of abstract concept
  developedBy:
    range: Person
    edge_properties:
      year: integer
    description: Who created/formalized this
  testedBy:
    range: Test
    description: Popperian tests applied

Method of modelling / Progressive differentitation

Yes. That is the right method.

Not full pairwise comparison of every subcomponent against every other one — that would explode the model too early — but a staged pressure test.

The sequence should be:

1. Define each subcomponent sharply For each proposed subcomponent, state:

function
core concern
characteristic failure mode
question it answers

That gives it an identity.

2. Boundary-test it against the parent Ask:

does this really stay inside the parent competency?
or is it leaking into another competency?

Example: if a “Learning” subcomponent sounds like truth-tracking, it probably belongs in Rationality instead. if it sounds like action selection, it probably belongs in Decision making.

3. Sibling differentiation Then compare it only against the other subcomponents of the same parent.

That is the key move. Not “compare everything to everything,” but:

Rationality subcomponents against other Rationality subcomponents
Learning subcomponents against other Learning subcomponents
Decision-making subcomponents against other Decision-making subcomponents

The test is:

distinct function
distinct failure signature
non-redundant question answered

If two subcomponents have the same job and same failure mode, one should collapse into the other.

4. Cross-parent leak test Only after sibling differentiation, check whether a subcomponent is actually misplaced.

Example:

a Learning subcomponent that is really about noticing evidence may belong partly to Attention or Rationality
a Decision-making subcomponent that is really about staying aligned may belong to Self-regulation

This is where you catch false decomposition.

5. Necessity test inside the parent Ask: if this subcomponent is absent, does the parent competency fail in a distinctive way? If not, it may not deserve to be there.

That gives you a local necessary-condition architecture for the parent.

So yes, the pattern is close to what you said, but more disciplined:

define
boundary-test
differentiate among siblings
leak-test across parents
necessity-test within parent

That is the clean pipeline.

A good compact standard is:

For each proposed subcomponent, we should be able to say:

Function: what it does
Boundary: what it is not
Failure mode: how the parent fails when this is weak
Diagnostic question: what specific question this subcomponent answers
Leak check: whether it actually belongs under another parent instead

That is enough to keep the ontology clean without pairwise-comparing everything against everything.

So the practical next move is: we take one parent at a time, probably Learning first, and for each candidate subcomponent we run that exact test.