215 lines
4.8 KiB
Markdown
215 lines
4.8 KiB
Markdown
Yes — you’re absolutely right, and thank you for calling this out.
|
||
What you’re seeing is not a small conflict, it’s a **layering collision**, and the correct fix is **not** to weaken ENC-TGK-CORE.
|
||
|
||
Let’s reset cleanly and reconcile the models.
|
||
|
||
---
|
||
|
||
## 1. What ENC-TGK-CORE already guarantees (and must not change)
|
||
|
||
From what you say, ENC-TGK-CORE already defines:
|
||
|
||
* An **edge** as:
|
||
|
||
* a list of *from* nodes
|
||
* a list of *to* nodes
|
||
* The encoding is **strict**
|
||
* This is the **semantic edge representation**, not an index artifact
|
||
|
||
That means:
|
||
|
||
> ENC-TGK-CORE defines *what an edge is*, not *how edges are indexed*.
|
||
|
||
So my previous draft **incorrectly redefined the edge shape** at the encoding layer. You’re correct to reject that.
|
||
|
||
---
|
||
|
||
## 2. Correct mental model (this is the key correction)
|
||
|
||
There are **three distinct things**:
|
||
|
||
| Layer | What it defines |
|
||
| ----------------------- | ------------------------------------------ |
|
||
| TGK-CORE / ENC-TGK-CORE | Edge *structure* (from[] → to[]) |
|
||
| TGK-INDEX | How edges are *located and filtered* |
|
||
| ENC-TGK-INDEX | Index records pointing *to* TGK-CORE edges |
|
||
|
||
👉 **ENC-TGK-INDEX must never encode the edge itself.**
|
||
It only encodes **references to edges**.
|
||
|
||
This is exactly analogous to ASL artifacts vs ASL index entries.
|
||
|
||
---
|
||
|
||
## 3. What must change in ENC-TGK-INDEX (conceptual patch)
|
||
|
||
ENC-TGK-INDEX must be rewritten as:
|
||
|
||
> *An index over immutable TGK-CORE edges, not a re-encoding of edges.*
|
||
|
||
That resolves the conflict cleanly.
|
||
|
||
---
|
||
|
||
## 4. Revised ENC-TGK-INDEX model (corrected)
|
||
|
||
### 4.1 What an index record refers to
|
||
|
||
A TGK index record must reference:
|
||
|
||
* A **TGK-CORE edge identifier**
|
||
* Snapshot / log sequence
|
||
* Routing and filtering attributes (edge type key, etc.)
|
||
* Optional projection context
|
||
|
||
But **never** re-encode `from[]` or `to[]`.
|
||
|
||
---
|
||
|
||
## 5. Canonical Edge Identity (reconciled)
|
||
|
||
Canonical Edge Key becomes:
|
||
|
||
```
|
||
CanonicalEdgeKey =
|
||
TGK_CORE_EDGE_ID
|
||
```
|
||
|
||
Where:
|
||
|
||
* `TGK_CORE_EDGE_ID` is defined *exclusively* by ENC-TGK-CORE
|
||
* Identity is stable and already well-defined
|
||
* Index never inspects edge structure
|
||
|
||
This is the cleanest possible boundary.
|
||
|
||
---
|
||
|
||
## 6. How filters work with multi-node edges
|
||
|
||
Because edges are `from[] → to[]`, the index supports **multiple logical projections** *without duplicating semantics*.
|
||
|
||
Indexing options (all valid):
|
||
|
||
1. **Edge-centric indexing** (default)
|
||
|
||
* One index record per edge
|
||
* Filter by edge type, snapshot, context
|
||
|
||
2. **Node-projection indexing** (optional acceleration)
|
||
|
||
* Additional index records mapping:
|
||
|
||
```
|
||
node_id → edge_id
|
||
```
|
||
* Pure acceleration
|
||
* Semantically redundant
|
||
|
||
This fits perfectly with ASL-INDEX-ACCEL.
|
||
|
||
---
|
||
|
||
## 7. What ENC-TGK-INDEX should actually contain
|
||
|
||
### 7.1 Correct index record shape
|
||
|
||
```c
|
||
struct tgk_index_record {
|
||
uint64_t logseq;
|
||
uint64_t tgk_edge_id; // references ENC-TGK-CORE edge
|
||
uint32_t edge_type_key; // optional
|
||
uint8_t has_edge_type;
|
||
uint8_t role; // from / to / both (optional)
|
||
uint16_t flags; // tombstone, etc.
|
||
};
|
||
```
|
||
|
||
* `tgk_edge_id` is the only identity reference
|
||
* No node lists here
|
||
* No semantic duplication
|
||
|
||
---
|
||
|
||
### 7.2 Optional projection index (acceleration only)
|
||
|
||
If needed:
|
||
|
||
```c
|
||
struct tgk_node_edge_ref {
|
||
uint64_t logseq;
|
||
uint64_t node_id;
|
||
uint64_t tgk_edge_id;
|
||
uint8_t position; // from or to
|
||
};
|
||
```
|
||
|
||
This is:
|
||
|
||
* Optional
|
||
* Redundant
|
||
* Fully derivable
|
||
* Clearly acceleration
|
||
|
||
---
|
||
|
||
## 8. Document changes required (precise)
|
||
|
||
### 🔁 Documents to UPDATE
|
||
|
||
#### TGK-INDEX
|
||
|
||
* Canonical Edge Key = TGK-CORE edge ID
|
||
* Explicit statement: index never encodes edge structure
|
||
|
||
#### ENC-TGK-INDEX
|
||
|
||
* Rewrite as **edge-reference index**
|
||
* Remove all `from[]` / `to[]` fields
|
||
* Reference ENC-TGK-CORE normatively
|
||
|
||
---
|
||
|
||
### 🚫 Documents NOT to touch
|
||
|
||
* ENC-TGK-CORE (must remain authoritative)
|
||
* TGK-CORE semantics
|
||
* PEL-TRACE
|
||
|
||
---
|
||
|
||
## 9. One sentence that should be normative (important)
|
||
|
||
Add this verbatim to ENC-TGK-INDEX:
|
||
|
||
> *ENC-TGK-INDEX encodes only references to TGK-CORE edges and MUST NOT re-encode or reinterpret edge structure.*
|
||
|
||
This single sentence prevents future drift.
|
||
|
||
---
|
||
|
||
## 10. Why this is actually a good sign
|
||
|
||
You caught this because your model is **internally consistent**.
|
||
|
||
What happened:
|
||
|
||
* Index draft accidentally crossed into core semantics
|
||
* You noticed because ENC-TGK-CORE is strict
|
||
* The fix strengthens layering, not weakens it
|
||
|
||
That’s exactly what you want at this stage.
|
||
|
||
---
|
||
|
||
## 11. Recommended next step
|
||
|
||
If you want, I can now:
|
||
|
||
* **Rewrite ENC-TGK-INDEX correctly**, fully aligned with ENC-TGK-CORE
|
||
or
|
||
* Produce a **one-page layering contract** between TGK-CORE, TGK-INDEX, and ASL-INDEX-ACCEL
|
||
|
||
Both will lock this down permanently.
|
||
|