Knowledge Capture

Core rule

Continuous Canonicalization

Discovery
   ↓
Repository Validation
   ├── small + sprint-relevant → Canonical Update → Continue Sprint
   └── larger or unrelated     → Idea Cache       → Continue Sprint

Repository validation

Active interface

2he cache <type> "<title>" --body "<context>"

Supported types: idea, todo, decision, question, issue, and research.

The command creates a timestamped Markdown record in Idea_Cache/. Every generated record is explicitly non-canonical until reviewed.

Lifecycle

Discovery
   ↓
Capture or Canonical Update
   ↓
Continue
   ↓
Review
   ↓
Experiment or Implement
   ↓
Canonicalize when proven
   ↓
Update Guide and Evolution when required

Captured ideas

Generated from the non-canonical Markdown records in Idea_Cache/, oldest first.

# Interactive Platform Navigation

**Capture ID:** `20260719T105610`  
**Type:** Idea  
**Status:** Captured — not canonical  
**Captured:** 2026-07-19

## Idea

Turn the generated 2HE platform architecture diagram into an interactive navigation surface.

Each architecture element could link to its canonical documentation and provide a concise contextual description on hover or focus. The same visual would then serve as architecture overview, documentation entry point, and platform navigation.

## Why it may matter

The platform architecture is already a high-value mental model. Making its elements directly navigable could reduce the distance between understanding the platform and opening the relevant canonical source.

## Origin context

The idea emerged while reviewing the first generated Platform Architecture diagram and considering how the Guide Platform could support rapid orientation without duplicating canonical information.

## Boundaries

- Do not implement interactive behavior during Knowledge Capture Foundation v1.0.
- Do not create manually maintained architecture relationships.
- Canonical architecture data must remain the single source of truth.
- Accessibility must include keyboard navigation and non-hover descriptions.
- Generated output should remain deterministic and build-validatable.

## Review question

Can interactive links and descriptions be generated entirely from canonical architecture metadata without weakening the current deterministic diagram-generation rule?

# Identity Foundation Remaining Concepts

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-19T11:15:00+02:00

## Capture

Continue the Identity foundation with Role, Assignment, Capability, Authority, Permission, Responsibility, and Trust. Role and Assignment were explored in conversation but have not yet been validated or promoted into canonical repository artifacts.

## Why it may matter

A reusable Identity model may support humans, AI partners, organizations, teams, automations, services, and repository developers across the 2HE-Eco.

## Boundary

Do not delay active implementation work merely to complete the ontology. Resume this work in a dedicated Identity sprint.

## Review

- Validate each concept against real cooperation and product use cases.
- Preserve clear separation between role, capability, authority, permission, and responsibility.
- Update the Guide and Evolution record only after canonical promotion.

# Canonical Domain Pattern

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-19T11:16:00+02:00

## Capture

Investigate a reusable domain structure built around Model, Concepts, Relationships, Operations, Lifecycle, and Examples.

## Why it may matter

A common pattern could make Identity, HVAC, Finance, Geometry, and future domains easier for humans and AI participants to understand and extend.

## Boundary

This is a working hypothesis, not a repository-wide convention. Validate it in at least Identity and one concrete engineering domain such as HVAC before promotion.

## Review

- Does the pattern support non-entity concepts, rules, formulas, and processes?
- Which elements are required and which are optional?
- Does domain locality remain clear?
- Is a formal convention justified by repeated use?

# Engineering Knowledge Stack

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-19T11:17:00+02:00

## Capture

Explore a layered model separating Philosophy, Governance, Knowledge, Processes, Products, and Implementations, together with the idea of a shared 2HE engineering language.

## Why it may matter

Clear layer boundaries could prevent principles, domain models, workflows, products, and technical implementations from being mixed together.

## Boundary

Do not introduce a repository-wide hierarchy until multiple real projects demonstrate that the distinction is useful and stable.

## Review

- Which layers already exist in repository practice?
- Are the proposed names precise and non-overlapping?
- Can the model support generation of documentation, schemas, APIs, tests, and implementations?
- Should the governance cycle be a process artifact rather than part of the knowledge hierarchy?

# Test Capture

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-19T11:53:09+00:00

## Capture

Captured for later review.

## Review

- Does this belong in the repository?
- Does an equivalent artifact already exist?
- What is the correct domain and artifact type?
- Is it mature enough to canonicalize or implement?
- Must the Guide or Evolution record be updated?

# GitHub Pages Test

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-19T12:31:19+00:00

## Capture

Captured for later review.

## Review

- Does this belong in the repository?
- Does an equivalent artifact already exist?
- What is the correct domain and artifact type?
- Is it mature enough to canonicalize or implement?
- Must the Guide or Evolution record be updated?

# 2HE Working Model for New Chats

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-21T15:09:27+00:00

## Capture

Proposal: establish a stable working model for new 2HE chats, preferably as part of the existing Repo Bootstrap. The model should require finishing the current working state before redesigning, preserving established terminology, collecting unproven improvements in the Idea Cache, and changing the backbone only where a clear practical benefit is demonstrated. Default behaviour: extend existing structures, distinguish canonical decisions from experiments and ideas, and return to implementation when architectural discussion increases cognitive load without practical value.

## Review

- Does this belong in the repository?
- Does an equivalent artifact already exist?
- What is the correct domain and artifact type?
- Is it mature enough to canonicalize or implement?
- Must the Guide or Evolution record be updated?

# 2HE Ecosystem as a Living Evolution System

**Type:** idea
**Status:** captured · non-canonical
**Captured:** 2026-07-22T19:00:00+02:00
**Origin:** Architecture consolidation conversation
**Scope:** 2HE__Ecosystem

## Capture

2HE__Ecosystem is itself a living evolution system. Its purpose is not only to hold standards, principles, capabilities, services, and workspaces, but also to provide the optimal improvement process for You.

The existing `xtools cache` idea must therefore be extended by an explicit evolution procedure:

1. A thought, discovery, issue, or improvement is formulated.
2. `xtools cache <type>` creates a Living Evolution Object as a non-canonical living document.
3. The object preserves origin, context, scope, relations, status, and history.
4. It can be reviewed, refined, tested, validated in consumer workspaces, promoted, adopted, rejected, superseded, or merged.
5. Canonical merge means that the validated knowledge is integrated into the appropriate 2HE__Ecosystem artifact and its evolution history remains traceable.

The object is not merely a temporary Markdown note. It is an evolving knowledge object whose state and relations are explicit.

## Candidate lifecycle

```text
Thought / Discovery
        ↓
Capture
        ↓
Living Evolution Object
        ↓
Review and Refinement
        ↓
Experiment / Consumer Validation
        ↓
Proposal
        ↓
Adoption Decision / ADR
        ↓
Canonical Integration
        ↓
Continuous Improvement
```

Possible terminal or transitional states include:

- captured
- reviewing
- refining
- experimenting
- validated
- proposed
- adopted
- integrated
- rejected
- superseded
- archived

## xtools implications

The current command:

```text
xtools cache idea "Title" --body "Context"
```

should remain the fast intake path, but its generated record should gain an evolution-oriented schema. Future commands may include:

```text
xtools evolve <object>
xtools promote <object>
xtools adopt <object>
xtools integrate <object>
xtools supersede <object>
```

Command names are not yet canonical. The lifecycle and data model must be defined before implementation.

## Living-system principle

> 2HE__Ecosystem must continuously improve the way it improves itself for You.

This implies a closed learning loop:

```text
You / Consumer Workspace
        ↓
Experience and Discovery
        ↓
Evolution Object
        ↓
Validation
        ↓
Ecosystem Improvement
        ↓
Improved support for You
```

## Pages implication

The GitHub Pages guide should reflect canonical `main` rapidly and automatically. The existing Pages workflow must be reviewed as a Fast-Lane Page Update mechanism so that every relevant merge or push to `main` rebuilds, validates, and deploys the current repository state without a separate manual synchronization step.

## Review

- Define the canonical term: Living Evolution Object, Evolution Object, or another ontology-aligned name.
- Define required metadata and lifecycle states.
- Decide how an object records relations, revisions, validation evidence, and canonical destination.
- Decide whether promotion changes one object in place or generates linked artifact types.
- Align Knowledge Capture, Evolution records, ADRs, Standards, Specifications, Guide, and Capability Registry.
- Validate the Pages workflow and build coverage against the complete canonical repository surface.