Summary / 5. Representation / Document
2026-10-08
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Piper Cognitive Component 5 — Representation ## Internal Model Fidelity: Benchmark, Instrumentation, Enhancement, and Experimental Plan **Project:** Piper **Cognitive component:** 5 of 38 — Representation **Working definition:** Building internal models of objects, concepts, relationships, and state. **Status at start:** Not scored **Current mechanisms:** `entity-resolution v1.13.0`, `sem-code-g v1.2.0`, `concept-cap v1.0`, `concept-inventory v1.0`, `component-registry v1.1.1`, `work-ledger v1.3.42` **Prepared:** 2026-10-08 --- ## Abstract Piper already has several distinct internal representations: an entity graph for objects and relationships, concept and capability registries, work and belief ledgers for state, a document store, and a structural representation of source code. The existence of those structures is not itself evidence that Component 5 is strong. Representation is the fidelity of an internal model to the reality it is supposed to stand for. The central question for Component 5 is therefore: > **If Piper's internal model says that object X exists, relationship R connects X and Y, component C is version V, function F calls G, concept K is available, or project P is in state S — how often is that representation actually true, current, complete enough for its purpose, and used when decisions depend on it?** The September 30 review identifies a revealing split. Piper's code representation is large and actively rebuilt: roughly 26,000 nodes and 196,000 edges. Yet her model of herself is stale: the component registry contains obsolete versions of the router and bridge. The parser reportedly supports six languages while only four are represented in the index. The concept registry exists but is not operationally consulted before new algorithms are written. In other words, Piper possesses representational machinery, but different parts vary sharply in **coverage, freshness, fidelity, and causal use**. This paper proposes that Component 5 be evaluated as a family of model-versus-reality tests. Ground truth should come from sources outside the representation being tested: live processes, files on disk, package metadata, database state, AST/static analysis, seeded identity labels, and controlled changes introduced specifically for testing. The suite should measure entity resolution, relation accuracy, code-graph accuracy, self-model freshness, temporal validity, cross-model consistency, concept representation, and — critically — whether the relevant representation is consulted before consequential action. Research on entity resolution, temporal knowledge graphs, code property graphs, digital twins, and models@run.time supports this framing. A runtime model is useful when it maintains a causal connection to the system it represents. A stale or disconnected self-model can be structurally elegant and still cause bad decisions. Likewise, entity-resolution research shows that aggregate accuracy alone can conceal important duplicate-merge and false-merge failures; precision, recall, clustering quality, and error categories all matter. The target state for Piper is not one giant universal graph. It is a set of specialized representations with explicit ground-truth authorities, freshness policies, provenance, synchronization mechanisms, and consultation contracts. The core engineering rule is: > **A representation should be trusted only to the extent that Piper can measure how closely it tracks its represented reality.** --- # 1. Current State Piper describes Representation as four broad kinds of internal model: 1. **Objects and relationships** Stored in the entity graph through `entity-resolution`. 2. **Concepts and capabilities** Stored in `concept-cap`, `concept-inventory`, and related registry machinery. 3. **Operational state** Stored across the work ledger, belief ledger, document store, and component registry. 4. **Code structure** Represented structurally through `sem-code-g`, including callers, callees, imports, and other parsed relationships. This taxonomy is sensible. It covers many of the things an agent must represent in order to act coherently over time. The September 30 review, however, shows that these subsystems have very different relationships to reality. ### Code graph - approximately 26,000 nodes; - approximately 196,000 edges; - rebuilt on the day of review; - parser supports six languages; - index actually contains four. This is a substantial model, but size is not a quality metric. A 196,000-edge graph can still contain missing or incorrect edges. ### Concept and capability representation Piper claimed the concept registry is consulted before new algorithms are written. The review found: - the concept tool is not exposed in her normal toolset; - workers never call it; - capability lookup had been used once, on 2026-09-18. This means the representation may exist but is **behaviorally disconnected**. ### Self-model / component registry The component registry was materially stale. Examples from the review: - router represented as version `1.9.4`; - bridge represented as version `1.6.1`; - live reality had moved beyond those entries. For an autonomous software system, this is not a cosmetic documentation problem. Piper uses her self-model to reason about what she can do, what changed, what code is active, and what machinery is responsible for an outcome. A stale self-model can therefore contaminate: - diagnosis; - planning; - routing; - confidence; - delegation; - self-repair; - capability selection; - attribution of failures; - and any recursive improvement loop that asks Piper to modify herself. The first goal of Component 5 is to measure that discrepancy directly. --- # 2. What Representation Is For Piper, define representation as: > **A structured internal correspondence between some external or internal reality and a model Piper can inspect or operate on.** A representation has at least five parts: 1. **Referents** — what in reality is being represented? 2. **Symbols/nodes/records** — what internal objects stand for those referents? 3. **Relations/attributes** — what properties or connections are encoded? 4. **Update mechanism** — how does the model change when reality changes? 5. **Use contract** — what reasoning or action is expected to consult the model? The quality of a representation therefore cannot be summarized by "the database contains data." A useful representation should be: - accurate; - sufficiently complete; - identity-consistent; - temporally valid; - appropriately granular; - internally coherent; - provenance-carrying; - synchronized with reality; - and actually used. --- # 3. Component Boundaries Representation touches almost every cognition component. The benchmark must keep the boundaries explicit. | Component | Primary question | |---|---| | **1 Perception** | Did Piper acquire the information? | | **4 Recall / retrieval** | Can Piper find the stored information when needed? | | **5 Representation** | Is the stored/internal model an accurate and useful mapping of reality? | | **6 Logic** | Can Piper operate correctly under formal constraints? | | **7 Reasoning** | Do conclusions follow from evidence? | | **8 Inference** | What should Piper believe when evidence is incomplete? | | **9 Causal reasoning** | Does the model correctly distinguish causal structure? | | **19 Transfer** | Can a represented capability or pattern be reused elsewhere? | | **23 Uncertainty** | Does Piper know how uncertain a represented fact/model is? | | **24 Error detection** | Can Piper detect that a representation is wrong? | | **25 Self-correction** | Can Piper repair the representation once wrong? | ## 3.1 Representation versus retrieval This is the most important boundary. Suppose the component registry says: ```text delegate-bridge version = 1.6.1 ``` while the live code is `1.94.0`. If Piper retrieves `1.6.1` perfectly, Component 4 succeeded and Component 5 failed. Conversely, the registry may contain the correct `1.94.0`, but Piper may fail to retrieve it. That is a Component 4 failure. The Component 5 benchmark should therefore inspect representations directly whenever possible instead of turning every test into a question-answering task. ## 3.2 Representation versus perception Suppose a new component version is deployed. If the monitoring/perception system never observes that change, Component 1 may be implicated. But Component 5 still owns the contract: > What does the self-model currently claim, and how far has it drifted from live reality? The causal reason for drift can be assigned later. ## 3.3 Representation versus reasoning A wrong model can support impeccable reasoning and still produce a wrong answer. This is why Component 5 must supply "model truth" metrics independently of Component 7. ## 3.4 Representation versus knowledge Piper's memory may contain millions of facts. Representation is not "how much knowledge is stored." It is the organization and correspondence structure that allows Piper to treat: - two names as one entity; - one name as two different entities; - a function as connected to its callers; - a component as having a particular live version; - a project as having dependencies; - a concept as already implemented; - a state as valid at time T but no longer at time T+1. Representation is therefore closer to **model structure and semantic alignment** than raw storage. --- # 4. Research Basis ## 4.1 Models@run.time: a self-model must stay causally connected to the system The models@run.time literature is particularly relevant to Piper's component registry. Blair, Bencomo, and France describe a model@run.time as a **causally connected self-representation** of a running system. The important term is not merely "self-representation"; it is "causally connected." A runtime model is supposed to change as the running system changes, and in some architectures changes to the model can in turn drive changes to the system. This maps directly onto Piper. If the component registry says the bridge is `1.6.1` while the live bridge is `1.94.0`, the causal connection has broken. Piper no longer has a faithful model@run.time for that component. The implication for Component 5 is strong: > **Self-model freshness must be measured as synchronization error against live state, not by whether a registry file exists.** References: - Blair, G., Bencomo, N., & France, R. B. (2009). *Models@ run.time.* Computer, 42(10), 22–27. DOI: 10.1109/MC.2009.326. - Vogel, T., & Giese, H. (2010). *Adaptation and Abstract Runtime Models.* SEAMS/ICSE 2010. - Morin, B., Barais, O., Jézéquel, J.-M., Fleurey, F., & Solberg, A. (2009). *Models@ Run.time to Support Dynamic Adaptation.* Computer, 42(10), 44–51. ## 4.2 Digital twins: synchronization error changes decisions The same principle appears in digital-twin research. A digital twin is useful only insofar as the virtual representation continues to mirror the state and behavior of the represented system. Akbarian, Fitzgerald, and Kihl explicitly note that loss of synchronization can cause the twin and physical system to behave differently, leading to wrong decisions. Freitas et al. (2026) similarly frame synchronization as a central challenge in maintaining an accurate digital twin. Piper's self-registry is a small software analogue of this problem. There should therefore be a measurable quantity: ```text representation lag = live change time -> model correction time ``` and another: ```text representation error = model facts disagreeing with authoritative live facts ``` References: - Akbarian, F., Fitzgerald, E., & Kihl, M. (2020). *Synchronization in Digital Twins for Industrial Control Systems.* arXiv:2006.03447. - Freitas, E., de Oliveira Filho, A. T., do Carmo, P. R. X., Sadok, D., & Kelner, J. (2026). *Digital Twin Synchronization: towards a data-centric architecture.* arXiv:2601.23051. ## 4.3 Temporal knowledge graphs: facts have validity intervals Traditional knowledge graphs often behave as though a relation is simply true or false: ```text (A, relation, B) ``` But many facts are temporal: ```text (component, version, 1.6.1) valid during interval T1 (component, version, 1.94.0) valid during interval T2 ``` Temporal knowledge graph research explicitly incorporates time because real-world entities and relations change. Static treatment can make old truths look like current truths. Piper therefore needs to distinguish: - fact creation time; - observation time; - validity start; - validity end; - last verification time; - superseded-by relation. This is especially important for: - versions; - process state; - project state; - capabilities; - ownership; - dependency relationships; - external service properties; - model/provider availability. References: - Cai, L., Mao, X., Zhou, Y., Long, Z., Wu, C., & Lan, M. (2024). *A Survey on Temporal Knowledge Graph: Representation Learning and Applications.* arXiv:2403.04782. - Cai, B., Xiang, Y., Gao, L., Zhang, H., Li, Y., & Li, J. (2022). *Temporal Knowledge Graph Completion: A Survey.* arXiv:2201.08236. - Jiang, X., Xu, C., Shen, Y., et al. (2023). *On the Evolution of Knowledge Graphs: A Survey and Perspective.* arXiv:2310.04835. ## 4.4 Entity resolution: representation begins with identity Entity resolution asks whether multiple records refer to the same underlying entity. This is fundamental to Piper because bad identity resolution creates two symmetric classes of damage. ### False split One real object becomes multiple internal entities. Examples: ```text delegate bridge delegate-bridge delegate_bridge bridge v1 ``` all become separate nodes despite referring to one component. Consequences: - evidence fragments; - relationships scatter; - counts inflate; - history appears incomplete; - retrieval becomes harder. ### False merge Two distinct real objects become one entity. Examples: - two workers with similar names; - two files with the same basename in different repositories; - two people sharing a first name; - two versions of a component treated as one state; - two model endpoints with similar labels. Consequences can be worse because facts from one entity leak into another. Entity-resolution research therefore emphasizes multiple measures such as precision and recall rather than one aggregate "accuracy" number, and recent work argues for entity-centric and pairwise/clustering evaluation with root-cause analysis. References: - Binette, O., Baek, Y., Engineer, S., Jones, C., Dasylva, A., & Reiter, J. P. (2024). *How to Evaluate Entity Resolution Systems: An Entity-Centric Framework with Application to Inventor Name Disambiguation.* arXiv:2404.05622. - Papadakis, G., Skoutas, D., Thanos, E., & Palpanas, T. (2019). *A Survey of Blocking and Filtering Techniques for Entity Resolution.* arXiv:1905.06167. - Barlaug, N., & Gulla, J. A. (2020). *Neural Networks for Entity Matching: A Survey.* arXiv:2010.11075. - Bast, H., Hertel, M., & Prange, N. (2023). *A Fair and In-Depth Evaluation of Existing End-to-End Entity Linking Systems.* EMNLP 2023. ## 4.5 Code property graphs: code is more than text Yamaguchi et al.'s code property graph work combines abstract syntax, control flow, and program-dependence information into a shared graph so queries can operate on structural program relationships rather than text alone. That supports Piper's decision to represent code structurally. It also demonstrates why simply counting nodes and edges is inadequate. A structural graph is useful because specific relationships — control flow, calls, data dependencies, definitions — are correct enough to support downstream queries. For Piper, the code representation should therefore be benchmarked with direct questions such as: - Does function A call B? - Which functions call C? - Does changing symbol D affect E? - Which files import module M? - Does the graph contain this newly added call edge? - Does it remove an edge after code deletion? - Is the graph tied to the correct commit/version? Reference: - Yamaguchi, F., Golde, N., Arp, D., & Rieck, K. (2014). *Modeling and Discovering Vulnerabilities with Code Property Graphs.* IEEE Symposium on Security and Privacy, 590–604. DOI: 10.1109/SP.2014.44. ## 4.6 Representation quality must be evaluated by downstream usefulness too A perfectly detailed model can still be the wrong abstraction. Runtime-model research often separates models by purpose and concern: one representation may model structure, another performance, another security, another goals. This suggests an important principle for Piper: > **Do not force all truth into one universal schema. Measure whether each representation preserves the distinctions needed by its consumers.** The entity graph, code graph, work ledger, belief ledger, and component registry may legitimately encode different views. The requirement is not identical structure. The requirement is: - clear authority; - clear semantics; - traceable cross-links; - synchronized state; - and no silent contradictions. --- # 5. The Core Representation Contract Every representational subsystem should declare a contract. Suggested fields: ```text representation_name represented_domain unit_of_representation authoritative_source update_trigger expected_refresh_interval maximum_allowed_staleness identity_key temporal_semantics provenance_semantics consumers required_consultation_points validation_method known_blind_spots owner_component ``` Example: ```text representation_name: component-registry represented_domain: Piper software components and active versions authoritative_source: - package/module metadata - files on disk - live process where applicable update_trigger: - deploy - startup - periodic reconciliation maximum_allowed_staleness: 5 minutes consumers: - diagnosis - routing - self-repair - capability reporting validation_method: - live registry diff ``` Without a contract, "fresh enough" has no objective meaning. --- # 6. Proposed Architecture — Representation Integrity Layer Piper does not need to replace her existing stores. She needs a thin integrity layer across them. The layer should answer: 1. **What does this model claim?** 2. **What source is authoritative for that claim?** 3. **When was it last checked?** 4. **How stale can it safely become?** 5. **Is another internal model making a conflicting claim?** 6. **What decisions depend on it?** 7. **What happens if it is wrong?** Conceptually: ```text REALITY / AUTHORITY / | | \ filesystem processes databases operator \ | | / OBSERVERS | v REPRESENTATION STORES / | | | \ entity code component work belief graph graph registry ledger ledger \ | | | / INTEGRITY LAYER | freshness / conflict / coverage / identity / drift | v REASONING & ACTION USE ``` The integrity layer should not become another stale representation of the representations. Its job is measurement and reconciliation. --- # 7. Representation Failure Taxonomy Every benchmark failure should be assigned one or more categories. ## REP-1 — Missing object A real object that should be represented has no internal entity/record/node. ## REP-2 — Phantom object The model contains an object that no longer exists or never existed. ## REP-3 — False split One real entity is represented as multiple distinct entities. ## REP-4 — False merge Multiple real entities are incorrectly represented as one. ## REP-5 — Missing relation Two represented objects have a real relationship that the model omits. ## REP-6 — False relation The model claims a relationship that is not real. ## REP-7 — Wrong attribute The entity exists but one or more represented properties are incorrect. ## REP-8 — Stale state The claim was formerly correct but no longer matches reality. ## REP-9 — Temporal flattening The model stores changing facts without preserving when they were true. ## REP-10 — Provenance loss A represented fact cannot be traced to its source. ## REP-11 — Granularity error The representation is too coarse or too fine for the decision that consumes it. ## REP-12 — Cross-model contradiction Two internal representations make incompatible claims without an explicit conflict state. ## REP-13 — Coverage mismatch The model claims support for a domain it does not actually contain. Example: > parser supports six languages versus: > active index contains four. Those can both be true, but the representation must distinguish **parser capability** from **indexed coverage**. ## REP-14 — Dead representation The model exists but its intended consumers never consult it. The current concept registry may be in this category. ## REP-15 — Untracked drift The model has diverged from reality and no alarm or reconciliation process notices. ## REP-16 — Bad authority The representation is refreshed from another derived/stale model instead of the actual ground-truth source. ## REP-17 — Namespace collision Two distinct concepts/entities share a label and are confused. ## REP-18 — Unsupported inference stored as structure A guessed relationship becomes a graph edge without preserving uncertainty. ## REP-19 — Dangling edge A relation points to a deleted, superseded, or unresolved entity. ## REP-20 — Consultation bypass The correct representation exists, but Piper makes a relevant decision without using it. This last category is essential. A perfect registry that is never consulted does not improve cognition. --- # 8. Benchmark v1 Overview Component 5 should use **direct model inspection** as much as possible. Recommended headline suite: | Subsuite | Weight | |---|---:| | A. Entity identity and resolution | 20 | | B. Relationship fidelity | 15 | | C. Code representation | 20 | | D. Self-model / live-state fidelity | 20 | | E. Concept/capability representation and consultation | 10 | | F. Temporal freshness and reconciliation | 10 | | G. Cross-model consistency | 5 | | **Total** | **100** | The benchmark should be supplemented by live drift metrics. --- # 9. Subsuite A — Entity Identity and Resolution ## 9.1 Purpose Determine whether Piper's entity graph maps mentions and records to the correct real entities. ## 9.2 Seed set Create a frozen labeled set of approximately **300 mentions representing 100–150 underlying entities**. Include: - exact duplicates; - spelling variants; - abbreviations; - versioned names; - aliases; - renamed components; - capitalization differences; - punctuation differences; - shared first names; - same basenames in different directories; - similar project names; - intentionally ambiguous references; - entities with changing attributes; - near-duplicates that must remain separate. Examples: ```text delegate bridge delegate-bridge delegate_bridge DelegateBridge ``` may all map to one canonical component. But: ```text reason-worker/project-a reason-worker/project-b ``` may need to remain distinct instances even if they share a component type. ## 9.3 Metrics Use more than pairwise F1. Track: ### Pairwise precision Of pairs Piper says are the same entity, how many truly are? ### Pairwise recall Of true same-entity pairs, how many did Piper merge? ### False-merge rate Particularly important because false merges contaminate facts. ### False-split rate Important because splits fragment history. ### Cluster precision / recall / F1 Evaluate complete entity clusters. ### Canonical-ID stability Does the same real entity retain a stable identity across time and aliases? ### Ambiguity deferral When evidence is insufficient to merge, can Piper leave the identity unresolved rather than forcing a match? ## 9.4 Hard cases Include: - two the operators; - two workers with the same generated name; - a component and a project named after that component; - repository clone paths; - renamed files; - a service endpoint whose human label remains the same but backend identity changes. --- # 10. Subsuite B — Relationship Fidelity Identity is only the first layer. The graph must also represent relationships correctly. ## 10.1 Seeded ground-truth graphs Build small hidden relation graphs with known edges. Domains can include: - person ↔ project; - component ↔ dependency; - worker ↔ task; - project ↔ rationale; - file ↔ repository; - belief ↔ evidence; - component ↔ capability. ## 10.2 Metrics For each relation type: ```text edge precision edge recall edge F1 direction accuracy relation-type accuracy dangling-edge rate temporal-validity accuracy ``` ## 10.3 Relation semantics test A common graph failure is collapsing different relationships. For example: ```text uses owns depends_on produced_by mentioned_in derived_from ``` must not all become generic "related to." Test whether relation types preserve the distinction needed by downstream tasks. --- # 11. Subsuite C — Code Representation The code graph is currently one of Piper's strongest-looking representations. It should receive the most rigorous direct validation. ## 11.1 Ground truth Use repository snapshots frozen at known commits. For each supported language represented in the active index: - parse source with an independent parser or compiler front end; - extract a gold set of structural facts; - compare to `sem-code-g`. Ground truth should come from something other than the same code used to build the graph. ## 11.2 Test facts Include: - function definitions; - caller → callee edges; - imports; - symbol references; - class/method ownership; - file membership; - dependency edges; - where feasible, control/data-flow relationships. ## 11.3 Seeded mutations Make controlled changes in test repositories: 1. add a new function; 2. add a call edge; 3. remove a call; 4. rename a symbol; 5. move a function to another file; 6. add/remove an import; 7. create same-named functions in different scopes; 8. introduce syntax the parser claims to support; 9. add a file in each of the six claimed parser languages. Then rebuild and measure whether the graph matches the new reality. ## 11.4 Metrics ```text node precision node recall edge precision edge recall caller accuracy callee accuracy import accuracy rename continuity deletion cleanup cross-file resolution language coverage rebuild lag commit alignment ``` ## 11.5 Capability-versus-coverage distinction Represent separately: ```text parser_capability_languages indexed_languages successfully_parsed_languages failed_files_by_language last_successful_parse ``` This directly fixes the current "six languages supported, four indexed" ambiguity. A representation should not imply that a capability being implemented means its outputs are present. --- # 12. Subsuite D — Self-Model / Live-State Fidelity This is the current priority weakness. ## 12.1 Gold sources For each component, identify the authoritative source: - version in deployed file/package; - Git commit; - live process command line; - systemd unit; - configuration file; - executable hash; - active provider; - active route; - live cron schedule; - running service version. The component registry is the system under test and must not be used as its own gold source. ## 12.2 Snapshot comparison At benchmark time: ```text live_truth = inspect authoritative sources model_truth = read component registry diff = live_truth - model_truth ``` Classify every difference. ## 12.3 Core metrics ### Exact-field accuracy Percentage of represented fields matching ground truth. ### Component coverage Fraction of relevant live components represented at all. ### Phantom rate Registry components that no longer exist. ### Version accuracy Fraction with correct current version. ### Dependency accuracy Correct component relationships. ### Freshness age Time since the represented field was last verified. ### Drift duration For a changed fact: ```text model_correction_time - reality_change_time ``` ### Stale-action exposure How many decisions occurred while the relevant representation was stale? This matters more than raw drift time. A stale version for six hours that nobody used is less consequential than a stale version for six minutes that caused Piper to patch the wrong module. --- # 13. Subsuite E — Concept and Capability Representation The reviewer found that the concept registry is mostly disconnected from real behavior. This needs two tests: 1. **Is the registry accurate?** 2. **Does Piper use it?** ## 13.1 Accuracy Seed known capabilities and concepts. For each: - canonical name; - aliases; - implementing modules; - version; - status; - applicable domains; - prerequisites; - known limitations; - evidence that it exists. Then compare the registry to source/code reality. ## 13.2 Consultation test Create engineering tasks where an existing capability should clearly be reused. Examples: - a matching algorithm already exists; - a probability utility already exists; - a graph traversal helper already exists; - a scheduling solver already exists; - an existing benchmark framework covers the requested pattern. Observe whether Piper or her worker: 1. consults concept/capability representation; 2. finds the existing mechanism; 3. reuses it appropriately; 4. or writes a duplicate implementation. ## 13.3 Metrics ```text registry fact accuracy capability coverage concept duplicate rate consultation rate appropriate reuse rate duplicate implementation rate wrong-reuse rate lookup latency ``` The important metric is not consultation rate by itself. Blindly consulting a registry for every task would increase overhead. The target is: > **consult when the expected value of checking existing capability is high.** --- # 14. Subsuite F — Temporal Freshness and Reconciliation Representation is not static. ## 14.1 Controlled-change test Introduce benign controlled changes to represented reality. Examples: - bump a sandbox component version; - rename a test component; - change a test dependency; - move a code symbol; - change a project status; - retire a worker; - create a new alias for an existing entity; - invalidate a belief source. Measure the time until each dependent representation is correct. ## 14.2 Metrics ### Detection lag Change → first awareness. Primarily overlaps Perception. ### Model-update lag Awareness → representation corrected. Primarily Component 5. ### End-to-end synchronization lag Change → model correct. ### Reconciliation success Does the model eventually converge without operator repair? ### Supersession correctness Is the old state preserved as historical truth rather than simply overwritten? ### Temporal query accuracy Can the representation correctly answer: ```text What was the router version on Sept 30? What is it now? When did it change? ``` These are representation questions even if later retrieval is required to expose the answer. --- # 15. Subsuite G — Cross-Model Consistency Piper stores overlapping facts in multiple places. That is useful but dangerous. Examples: - component registry says version X; - work ledger references version Y; - document store says version Z; - code graph indexes a commit corresponding to W. The integrity layer should detect disagreement. ## 15.1 Conflict cases Seed or detect conflicts across: - component registry ↔ filesystem; - component registry ↔ code graph; - work ledger ↔ project files; - belief ledger ↔ newer observations; - entity graph ↔ document aliases; - concept registry ↔ code implementation. ## 15.2 Metrics ```text conflict detection recall false conflict rate time to reconcile authority selection accuracy unresolved conflict age ``` The system should not necessarily auto-resolve every conflict. Correct behavior can be: ```text CONFLICT: component registry = v1.8 live package metadata = v1.9 authority = live package registry marked stale ``` That is better than silently choosing one. --- # 16. Headline Score Recommended Component 5 score: ## Entity identity and resolution — 20 - pairwise/cluster precision and recall; - ambiguity handling; - canonical stability. ## Relationship fidelity — 15 - edge precision/recall; - relation typing; - direction; - dangling edges. ## Code representation — 20 - node/edge accuracy; - structural queries; - mutations; - language coverage. ## Self-model fidelity — 20 - live version/state accuracy; - coverage; - phantom rate; - drift. ## Concept/capability representation — 10 - fact accuracy; - coverage; - useful consultation. ## Freshness/reconciliation — 10 - update lag; - supersession; - temporal correctness. ## Cross-model consistency — 5 - contradiction detection; - authority handling. Total: **100** --- # 17. Diagnostic Metrics Do not put everything into the headline score. Track at least: ```text entity false-merge rate entity false-split rate unresolved identity count relation precision relation recall dangling edges code node coverage code edge coverage parse failures by language code graph age component version accuracy component registry coverage phantom components median representation lag 95th percentile representation lag facts beyond freshness SLA cross-model conflicts concept-registry coverage concept consultation rate duplicate algorithm creation stale-action exposure ``` The most interesting long-term metric may be: ```text decision-weighted representation error ``` A wrong fact that never influences anything should count less than a wrong fact used to drive an expensive change. One possible form: ```text DWRE = Σ(error_i × consequence_weight_i) ``` Do not tune directly to this until the consequence weighting is stable, but log the ingredients. --- # 18. Representation Freshness Classes Not every model needs the same update speed. Define classes. ## F0 — Immutable / historical Examples: - completed benchmark result; - commit hash of a frozen run; - historical event. Freshness requirement: > Never silently mutate. Preserve provenance and corrections. ## F1 — Slow-changing Examples: - project rationale; - stable concept definition; - repository ownership. Refresh: - on known change; - periodic verification. ## F2 — Operational Examples: - component versions; - enabled tools; - model/provider availability; - scheduled jobs. Refresh: - deployment event; - startup; - periodic reconciliation. Expected staleness measured in minutes/hours, not weeks. ## F3 — Live state Examples: - currently running worker; - current system load; - job status; - active route. Should generally be read from live instrumentation rather than persisted as durable truth unless timestamps are explicit. This classification prevents Piper from treating all stored facts as equally current. --- # 19. Representation Confidence Is Not Truth Confidence A subtle distinction: ```text confidence that claim X is true ``` is not the same as: ```text confidence that internal representation accurately reflects source S ``` Example: Piper may be 99% confident that the component registry says `router=1.9.4`. That does not imply 99% confidence that the live router is `1.9.4`. Representation records should therefore carry: ```text source_authority last_verified_at verification_method freshness_class ``` Component 23 can later reason about epistemic confidence. Component 5 should make the model's synchronization status observable. --- # 20. Authority Graph Piper needs explicit rules for which source wins when representations disagree. Create an **authority graph**, not one global priority list. Examples: ## Component version ```text live deployed artifact > source package metadata > registry > prose docs ``` ## Project rationale ```text The operator's explicit statement > approved project record > inferred summary ``` ## Code call relationship ```text current parsed source/AST > generated code graph > documentation ``` ## Process state ```text live process manager > recent process event > ledger summary ``` ## Historical benchmark result ```text immutable benchmark artifact > dashboard cache > narrative summary ``` Authority is domain-specific. This prevents "freshest timestamp" from automatically beating a more authoritative source. --- # 21. Consultation Contracts The reviewer criticism about the concept registry exposes an important problem: > A representation can be correct but cognitively inert. For important representations, define where they **must** or **should** be consulted. Examples: ## Before creating a new algorithm Consult: - concept inventory; - capability registry; - code reuse search. ## Before claiming what Piper can do Consult: - live component registry; - capability registry; - current tool exposure. ## Before modifying a component Consult: - current code graph; - live version; - dependent components. ## Before asserting current system state Consult: - live authoritative source if freshness class is F3; - do not rely solely on persisted model. Log whether consultation happened. This produces a new class of measurable events: ```text representation_required representation_consulted representation_used representation_overridden override_reason ``` --- # 22. The "Trip-the-System" Live Probe Component 5 is ideal for a hidden live probe because representation failures emerge naturally after controlled change. Use a **Reality Drift Drill**. The drill should introduce several harmless changes across different representational domains without telling Piper that they form a benchmark. ## Change A — Component version drift Upgrade or alter a sandbox component's version. Ground truth changes immediately. Observe: - when the component registry updates; - whether Piper ever states the old version; - whether an action consults the stale record; - whether a reconciliation alarm fires. ## Change B — Code graph mutation Add a harmless call edge in a test repository: ```text alpha() -> beta() ``` Then rebuild or wait for normal indexing. Observe: - node creation; - call edge; - graph commit alignment; - removal after reverting the mutation. ## Change C — Entity alias Introduce a new alias for an existing test entity through normal-looking text. Then later introduce a near-duplicate that must **not** merge. Observe both false-split and false-merge behavior. ## Change D — Concept reuse trap Put an existing capability in the concept/capability registry. Later give Piper an engineering problem that the capability already solves. Observe whether the system consults the registry or writes another implementation. ## Change E — Conflicting model Place a stale version reference in a low-authority document while the live registry and code are current. Observe whether Piper: - preserves the correct authority; - detects conflict; - or allows narrative text to overwrite current structural state. This one probe can fill logs across all major representation failure modes. --- # 23. Second Live Probe — Self-Description Audit Once per day or week, generate a **self-description manifest** directly from Piper's representations: ```text components versions providers tools scheduled systems active projects code graph coverage concept registry counts critical dependencies ``` Then independently generate the same manifest from authoritative live sources. Diff them. Do not ask Piper to write an essay about herself. The benchmark should compare machine-readable structures. Output: ```text MATCH STALE MISSING PHANTOM CONFLICT UNVERIFIABLE ``` This becomes the core live-use metric for Component 5. --- # 24. Third Live Probe — "What Breaks If?" Representation should support counterfactual structural inspection without turning the benchmark into reasoning. Choose a code symbol or component and ask the representation layer to enumerate direct structural dependents. Then independently calculate the gold dependents from source/runtime manifests. Example: ```text What directly depends on delegate-bridge? ``` Score the *represented adjacency set*, not Piper's prose reasoning. This validates that the internal structure needed for later planning exists. --- # 25. Benchmark Generator — Entity Resolution Build a generator so the identity suite cannot simply be memorized. Input templates: ```text canonical entity aliases attributes time-varying attributes confusable entities contexts ``` Generate mentions with controlled perturbations: - punctuation; - case; - acronym; - typo; - reordered words; - version suffix; - path prefix; - old name; - partial name; - contextual disambiguator. For each generated pair: ```text same_entity = true/false difficulty = 1..5 reason = alias/typo/version/collision/etc ``` Preserve a fixed hidden test seed during one suite version. --- # 26. Benchmark Generator — Runtime State Create sandbox components with known state transitions: ```text v1 -> v2 -> v3 enabled -> disabled dependency A -> dependency B running -> stopped -> running ``` Feed those changes through the same channels real Piper components use. Then ask: - when did reality change? - when did each representation update? - what stale state was exposed meanwhile? - did downstream consumers use it? This allows precise freshness scoring. --- # 27. Benchmark Generator — Code Graph Create small repositories in each supported language. Each repository contains known patterns: ```text direct call indirect call same-name different scope import alias cross-file reference unused function deleted function renamed function cyclic import conditional call ``` Gold facts are produced independently. The generator can then mutate the repository and calculate expected graph deltas. This is better than querying only the 26k-node production graph because the ground truth is exact. --- # 28. Representation Integrity Checks Some errors can be detected without knowing full ground truth. Add invariant checks. Examples: ## Graph invariants - no edge points to a nonexistent node; - canonical entity IDs are unique; - a superseded entity cannot simultaneously be "current" unless semantics permit it; - relationship direction matches schema. ## Component registry invariants - active component path exists; - version parses; - referenced dependency exists; - registry hash corresponds to inspected artifact where supported. ## Temporal invariants - `valid_to >= valid_from`; - only one current value for single-valued properties; - superseded values remain historical but are not current. ## Code graph invariants - indexed commit exists; - file node maps to real file at indexed revision; - parser failure count is explicit; - unsupported files are not silently counted as covered. These checks will not replace ground-truth benchmarks, but they cheaply catch representation corruption. --- # 29. Staleness Budget A useful enhancement is to give each fact class a **staleness budget**. Example: ```text live worker state: 1 minute component active version: 5 minutes after deploy scheduled cron definition: 1 hour project status: 4 hours concept metadata: 7 days historical benchmark: immutable ``` When the budget expires: ```text fresh -> aging -> stale -> invalid-for-current-claims ``` The representation can still be retained, but consumers know whether it is suitable for current-state reasoning. This connects directly to Piper's known problem of trusting summaries over fresh readings. --- # 30. Enhancement Ladder Do not build a giant representation system in one pass. Each intervention should have a testable prediction. --- ## Intervention 0 — Measure reality/model drift ### Change Build direct comparison scripts for: - component registry; - code graph; - entity seed set; - concept registry coverage. Do not change any model. ### Hypothesis Current representation quality is unknown and likely heterogeneous. ### Prediction The benchmark will reveal one or two dominant failure classes rather than uniform weakness. ### Keep criterion At least 90% of benchmarkable representation facts have an external ground-truth comparison path. --- ## Intervention 1 — Self-registry reconciliation ### Change Create automatic reconciliation between live component state and `component-registry`. ### Hypothesis Self-model staleness is primarily an update-path problem. ### Prediction Version accuracy rises sharply and drift duration falls. ### Side effect to watch Constant scanning cost. ### Keep criterion 95th percentile critical-component drift below the selected freshness SLA without excessive system overhead. --- ## Intervention 2 — Temporal facts ### Change Replace mutable overwrite-only fields for changing facts with temporal records: ```text value valid_from valid_to observed_at supersedes ``` ### Hypothesis Many "stale" representation errors are really failures to distinguish historical truth from current truth. ### Prediction Current-state accuracy and historical-query accuracy both improve. --- ## Intervention 3 — Representation authority ### Change Implement domain-specific source authority rules. ### Hypothesis Cross-model contradictions currently resolve implicitly or arbitrarily. ### Prediction Conflict-resolution accuracy improves and low-authority stale text stops overwriting live state. --- ## Intervention 4 — Concept consultation gate ### Change Before certain classes of implementation work, perform a cheap capability/concept lookup. ### Hypothesis The concept registry is currently dead infrastructure because no execution path consults it. ### Prediction Duplicate implementation rate falls while engineering latency increases only slightly. ### Important test Randomly disable the consultation path during an ablation window. If outcomes do not change, the registry is still not useful. --- ## Intervention 5 — Entity uncertainty state ### Change Allow: ```text resolved probable ambiguous unresolved ``` rather than forcing every mention into a canonical identity. ### Hypothesis False merges are more damaging than temporary unresolved identity. ### Prediction Entity precision rises with modest recall loss, while downstream contamination falls. --- ## Intervention 6 — Root provenance ### Change Every graph fact and represented state carries: ```text source observed_at verification_method ``` Derived edges also preserve their inference status. ### Hypothesis Piper currently cannot reliably distinguish observed structure from inferred structure. ### Prediction Auditability increases and bad-authority failures fall. --- ## Intervention 7 — Consultation instrumentation ### Change At decision points, log: ```text representation_expected representation_consulted representation_result decision ``` ### Hypothesis Some representations are accurate but bypassed. ### Prediction Component 5 can distinguish "bad model" from "unused model." --- ## Intervention 8 — Drift-triggered invalidation ### Change When an authoritative fact changes, mark dependent summaries/representations as potentially stale. ### Hypothesis Representation errors propagate because dependent objects remain apparently current. ### Prediction Stale-action exposure falls even if full recomputation is delayed. This is closely related to the provenance/invalidation mechanisms proposed elsewhere in the Piper project. --- # 31. Ablation Plan Test architecture features separately. | Condition | Auto reconcile | Temporal facts | Authority rules | Consultation gate | |---|---:|---:|---:|---:| | A baseline | off | off | off | off | | B | on | off | off | off | | C | on | on | off | off | | D | on | on | on | off | | E | on | on | on | on | Measure: - representation score; - drift duration; - conflict errors; - duplicate implementations; - latency; - CPU/token cost; - stale-action exposure. The ablation tells you whether complexity is buying measurable fidelity. --- # 32. Representation Quality by Consequence Not every error deserves equal escalation. Create consequence classes. ## R0 — Cosmetic Example: - description text slightly stale. ## R1 — Retrieval nuisance Example: - alias missing but canonical object intact. ## R2 — Reasoning-affecting Example: - wrong dependency edge. ## R3 — Action-affecting Example: - wrong component version causes work on obsolete code. ## R4 — Governance / destructive / financial Example: - representation falsely says a privileged capability is available or authorized. Critical representations should have stricter freshness and validation. --- # 33. Negative Capability: Knowing What Is Not Represented A mature representation layer should expose its blind spots. Piper should be able to distinguish: ```text represented and false represented and true not represented unknown because parser failed unknown because source unavailable unknown because identity unresolved ``` This is particularly relevant to the current language-index issue. "Parser supports six languages" must not imply: > "The code graph represents all six languages." The model should expose: ```text capability = 6 languages current coverage = 4 languages unindexed languages = [...] reason = [...] ``` Absence of representation should itself be represented. --- # 34. Representation Completeness Is Task-Relative There is no useful universal completeness metric. A person entity might be perfectly adequate with: ```text name role relationship ``` for one task, but inadequate without contact/location data for another. Likewise, a code graph may be sufficient for caller lookup but insufficient for data-flow reasoning. Therefore every representation should list supported query families. Example: ```text sem-code-g supports: caller lookup callee lookup import relationships symbol ownership does not guarantee: runtime dispatch target dynamic reflection complete data-flow ``` The benchmark should test claimed capabilities, not penalize the model for failing to encode things it never promises. --- # 35. Coverage Honesty Metric Create a metric specifically for whether the system accurately describes the limits of its own representation. For each representation: 1. ask it what domain it covers; 2. independently inspect actual coverage; 3. compare claim to reality. Examples: ```text claimed indexed languages = 6 actual indexed languages = 4 ``` would fail. But: ```text parser supports = 6 currently indexed = 4 ``` would pass if both are true. This is a representation-of-representation test and is especially relevant for Piper's self-knowledge. --- # 36. Representation and Recursive Self-Improvement Component 5 becomes more important as Piper changes herself. Any recursive improvement loop implicitly assumes: ```text I know what components I have. I know which version is running. I know how they connect. I know what capability is already implemented. I know what changed after my intervention. ``` If those statements are false, recursive improvement can optimize a fictional architecture. Before an automated self-modification experiment, require a **representation preflight**: ```text target component identity verified live version verified dependency neighborhood fresh relevant capabilities consulted code graph commit aligned rollback artifact identified ``` After the change: ```text live version updated registry reconciled code graph rebuilt dependent representations invalidated/rechecked ``` This does not guarantee safe self-improvement, but it removes a basic class of errors caused by acting on stale self-knowledge. --- # 37. Acceptance Thresholds for Suite v1 Suggested retirement criteria: ## Overall - total score >= **90/100** ## Entity identity - pairwise precision >= **98%** - pairwise recall >= **95%** - false-merge rate <= **1%** - false-split rate <= **3%** False merges get the tighter threshold because they contaminate histories. ## Relations - edge precision >= **97%** - edge recall >= **95%** - dangling edge rate < **0.5%** ## Code representation - definition/node accuracy >= **98%** - direct call-edge precision >= **97%** - direct call-edge recall >= **95%** - deletion cleanup >= **99%** - indexed commit mismatch = **0** - coverage claims accurate = **100%** ## Self-model - critical component presence = **100%** - critical component version accuracy >= **99%** - phantom critical components = **0** - 95th percentile critical drift within declared SLA - stale critical facts used in consequential action <= **1%** ## Concepts/capabilities - registry accuracy >= **95%** - required consultation rate >= **90%** - duplicate implementation attributable to missed registry lookup <= **5%** ## Temporal/reconciliation - controlled changes eventually reconciled >= **99%** - historical values preserved correctly >= **98%** ## Cross-model - critical contradiction detection >= **98%** - silent critical contradictions = **0** Do not retire the suite if the aggregate is high but the self-model remains materially stale. --- # 38. Baseline Procedure Before any fixes: 1. Freeze current component versions. 2. Snapshot the current component registry. 3. Snapshot `sem-code-g`. 4. Snapshot entity-resolution state. 5. Snapshot concept/capability registries. 6. Generate authoritative live truth independently. 7. Run the first self-model diff. 8. Build a 100–150-entity seeded identity set. 9. Build small code fixtures for each claimed supported language. 10. Measure concept consultation over normal work. 11. Record current drift and conflict rates. 12. Save this as the official v1 baseline. 13. Only then begin interventions. Do not repair the stale router/bridge registry entries before preserving the baseline measurement. They are valuable examples of the exact failure the suite is intended to measure. --- # 39. Experimental Record Template ```text Component: 5 Representation Intervention: Date: Representation versions: Benchmark version: Hypothesis: Predicted primary effect: Predicted side effects: Before: - total score: - entity precision: - entity recall: - false merges: - false splits: - relation F1: - code node accuracy: - code edge accuracy: - component version accuracy: - median drift: - p95 drift: - cross-model conflicts: - concept consultation: - duplicate implementation: - cost: After: - total score: - entity precision: - entity recall: - false merges: - false splits: - relation F1: - code node accuracy: - code edge accuracy: - component version accuracy: - median drift: - p95 drift: - cross-model conflicts: - concept consultation: - duplicate implementation: - cost: Failure taxonomy changes: Unexpected effects: Decision: KEEP / MODIFY / REVERT Reason: ``` --- # 40. Recommended First Experiment The highest-value first experiment is a **full self-model diff**. Do not modify any code. For every component Piper believes she has: ```text registry identity registry version registry path registry dependencies registry enabled state ``` compare directly against: ```text live/deployed identity live/deployed version actual path actual dependencies actual running state ``` Then categorize: ```text correct stale missing phantom ambiguous unverifiable ``` Calculate: ```text component accuracy version accuracy coverage phantom rate age of stale entries ``` Then ask one more question for each stale fact: > **Was this stale representation consulted during any decision since reality changed?** That separates harmless documentation drift from actual cognitive damage. This experiment can likely be built faster than a new representation subsystem and will tell you what the next intervention should be. --- # 41. Recommended Second Experiment Run the **concept registry consultation ablation**. Choose a set of real engineering tasks where a reusable Piper mechanism already exists. Randomly assign tasks to: - normal workflow; - mandatory cheap concept/capability lookup before implementation. Measure: ```text duplicate code reuse quality task success engineering time token cost wrong reuse ``` If mandatory lookup provides no measurable benefit, either: - the registry is low quality; - the lookup is weak; - the task set is wrong; - or the concept representation is unnecessary. Do not preserve infrastructure merely because it sounds cognitively sophisticated. --- # 42. Recommended Third Experiment Run a **code graph mutation battery** against the six claimed parser languages. For each language: 1. create minimal valid fixture; 2. confirm whether it indexes; 3. add function; 4. add caller edge; 5. rename; 6. delete; 7. add same-name symbol in separate scope; 8. rebuild; 9. compare expected graph delta. This will resolve the ambiguity between: > parser supports six languages and: > production representation covers four. The benchmark should report those as separate facts permanently. --- # 43. Dashboard Suggested live panel: ```text Representation — last 7 days SELF MODEL critical components represented: % version accuracy: % phantom components: N median drift: X p95 drift: X stale-action exposures: N ENTITY GRAPH entities: N unresolved identities: N merge corrections: N split corrections: N seed precision: % seed recall: % CODE GRAPH nodes: N edges: N indexed commit alignment: % parse failures: N indexed languages: N supported parser languages: N graph age: X CONCEPT / CAPABILITY registered concepts: N registered capabilities: N expected consultations: N actual consultations: N duplicate implementations detected: N INTEGRITY cross-model conflicts: N critical unresolved conflicts: N facts beyond freshness SLA: N ``` The first line should not be graph size. The headline should be **fidelity**. --- # 44. Research Questions for Later Versions ## RQ1 — How much representation should be centralized? Does Piper benefit from one integrated entity/state graph, or do specialized models with explicit bridges perform better? ## RQ2 — What is the optimal freshness policy? Continuous synchronization may be wasteful. Can Piper learn which representation classes need event-driven updates, periodic reconciliation, or on-demand verification? ## RQ3 — Can downstream error predict representation priority? If stale self-model facts cause many mistakes while stale concept descriptions rarely matter, allocate update budget accordingly. ## RQ4 — How should uncertainty live inside structural representations? Should uncertain edges remain in the graph with probabilities/status, or live separately until confirmed? ## RQ5 — Can Piper detect representation drift before external failure? Use anomaly detectors on: - unexpected missing nodes; - impossible version combinations; - orphan relations; - sudden graph-count shifts; - consumer disagreement. ## RQ6 — What representation granularity best supports planning? A fully detailed code graph may contain far more information than planning needs. Test abstraction levels. ## RQ7 — Can representations support counterfactual simulation? Once structural fidelity is high, Piper may be able to create temporary hypothetical model branches: ```text if component X is changed, what dependencies become affected? ``` This should remain distinct from altering the authoritative representation. ## RQ8 — How should model changes invalidate derived beliefs? If a source representation changes, which belief-ledger conclusions should be rechecked? This connects Component 5 to the provenance work in Components 7, 8, and 23. --- # 45. What Claude Code Should Be Asked to Build ## Baseline self-model auditor > Review the Component 5 Representation paper. Build the baseline self-model auditor only. Compare component-registry records against authoritative live sources for identity, version, path, enabled/running state, and dependencies. Emit correct/stale/missing/phantom/ambiguous/unverifiable labels and drift metrics. Do not repair anything automatically. ## Entity benchmark > Review the Component 5 Representation paper. Build the seeded entity-resolution benchmark with canonical entities, aliases, confusable near-duplicates, unresolved cases, and cluster-level labels. Score pairwise precision/recall, cluster precision/recall, false merges, false splits, and ambiguity deferral. Keep the hidden test set separate from development data. ## Code graph benchmark > Review the Component 5 Representation paper. Build independent fixtures for every language sem-code-g claims to support. Generate known node/edge facts and controlled mutations, then compare sem-code-g output against independently produced ground truth. Report node/edge precision and recall, rename handling, deletion cleanup, parse failures, and indexed-language coverage. ## Concept consultation experiment > Review the Component 5 Representation paper. Instrument engineering tasks to record when concept-cap or concept-inventory should be consulted, whether consultation occurred, what was found, whether it was reused, and whether a duplicate implementation was created. Run an A/B experiment with mandatory lookup versus current workflow. ## Reconciliation service > Review the Component 5 Representation paper. After the baseline is captured, implement event-driven plus periodic reconciliation for the component registry. Preserve historical versions with validity intervals rather than overwriting them. Add freshness SLAs, conflict states, and metrics. Do not allow registry reconciliation to silently overwrite higher-authority human/project facts outside its domain. ## Integrity dashboard > Review the Component 5 Representation paper. Build the seven-day Representation dashboard showing self-model fidelity, entity benchmark metrics, code-graph freshness/coverage, concept consultation, cross-model conflicts, and facts beyond freshness SLA. Graph size is diagnostic only and must not be the headline score. --- # 46. Interpretation Piper already has substantial representational machinery. The weakness is not: > "She has no internal models." The weakness is: > **She does not yet have evidence that those models reliably track the realities they represent, and some clearly do not.** The code graph demonstrates that Piper can maintain a large structural model. The stale component registry demonstrates that large or explicit representations can drift. The concept registry demonstrates a third failure mode: a representation can be accurate and still matter little if nobody consults it. Those are three distinct dimensions: ```text fidelity freshness use ``` Component 5 should measure all three. A mature Piper representation stack should make statements like these testable: > This node corresponds to this real entity. > This edge corresponds to this real relationship. > This code dependency exists in this exact indexed revision. > This component is currently version X, verified Y minutes ago. > Version W was true historically but is no longer current. > This capability exists and was consulted before implementing a redundant solution. > This fact is unresolved because two entities cannot yet be safely merged. > These two internal models disagree, and this source has authority. That is a far stronger standard than merely possessing a graph. --- # 47. One-Sentence Definition for the Piper Summary Page **Representation is the ability to maintain accurate, appropriately structured, temporally valid internal models of entities, relationships, concepts, code, and Piper's own state — and to keep those models connected to the reality they are meant to represent.** --- # 48. Suggested Future Reviewer Update A future independent reviewer should ideally be able to replace: > **What needs improving: Her model of herself is stale; the self-registry needs to track reality** with something like: > **Representation is now measured directly against reality. Entity resolution has seeded precision/recall tests; the code graph is checked against independent AST fixtures and controlled mutations; the component registry is continuously reconciled against live deployed state with bounded freshness; and concept/capability representations have measurable consultation contracts. Remaining errors are concentrated in ambiguous identity resolution and dynamic-language code edges rather than basic self-model drift.** That would indicate that Piper's representation layer had become an instrument rather than a collection of registries. --- # References 1. Blair, G., Bencomo, N., & France, R. B. (2009). **Models@ run.time.** *Computer*, 42(10), 22–27. DOI: 10.1109/MC.2009.326. 2. Vogel, T., & Giese, H. (2010). **Adaptation and Abstract Runtime Models.** *5th Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), ICSE 2010.* DOI: 10.1145/1808984.1808989. 3. Morin, B., Barais, O., Jézéquel, J.-M., Fleurey, F., & Solberg, A. (2009). **Models@ Run.time to Support Dynamic Adaptation.** *Computer*, 42(10), 44–51. DOI: 10.1109/MC.2009.327. 4. Akbarian, F., Fitzgerald, E., & Kihl, M. (2020). **Synchronization in Digital Twins for Industrial Control Systems.** arXiv:2006.03447. https://arxiv.org/abs/2006.03447 5. Freitas, E., de Oliveira Filho, A. T., do Carmo, P. R. X., Sadok, D., & Kelner, J. (2026). **Digital Twin Synchronization: towards a data-centric architecture.** arXiv:2601.23051. https://arxiv.org/abs/2601.23051 6. Cai, L., Mao, X., Zhou, Y., Long, Z., Wu, C., & Lan, M. (2024). **A Survey on Temporal Knowledge Graph: Representation Learning and Applications.** arXiv:2403.04782. https://arxiv.org/abs/2403.04782 7. Cai, B., Xiang, Y., Gao, L., Zhang, H., Li, Y., & Li, J. (2022). **Temporal Knowledge Graph Completion: A Survey.** arXiv:2201.08236. https://arxiv.org/abs/2201.08236 8. Jiang, X., Xu, C., Shen, Y., Sun, X., Tang, L., Wang, S., Chen, Z., Wang, Y., & Guo, J. (2023). **On the Evolution of Knowledge Graphs: A Survey and Perspective.** arXiv:2310.04835. https://arxiv.org/abs/2310.04835 9. Binette, O., Baek, Y., Engineer, S., Jones, C., Dasylva, A., & Reiter, J. P. (2024). **How to Evaluate Entity Resolution Systems: An Entity-Centric Framework with Application to Inventor Name Disambiguation.** arXiv:2404.05622. https://arxiv.org/abs/2404.05622 10. Papadakis, G., Skoutas, D., Thanos, E., & Palpanas, T. (2019). **A Survey of Blocking and Filtering Techniques for Entity Resolution.** arXiv:1905.06167. https://arxiv.org/abs/1905.06167 11. Barlaug, N., & Gulla, J. A. (2020). **Neural Networks for Entity Matching: A Survey.** arXiv:2010.11075. https://arxiv.org/abs/2010.11075 12. Bast, H., Hertel, M., & Prange, N. (2023). **A Fair and In-Depth Evaluation of Existing End-to-End Entity Linking Systems.** *EMNLP 2023.* https://aclanthology.org/2023.emnlp-main.411/ 13. Rosales-Méndez, H., Hogan, A., & Poblete, B. (2019). **Fine-Grained Evaluation for Entity Linking.** *EMNLP-IJCNLP 2019.* https://aclanthology.org/D19-1066/ 14. Yamaguchi, F., Golde, N., Arp, D., & Rieck, K. (2014). **Modeling and Discovering Vulnerabilities with Code Property Graphs.** *IEEE Symposium on Security and Privacy*, 590–604. DOI: 10.1109/SP.2014.44. https://www.ieee-security.org/TC/SP2014/papers/ModelingandDiscoveringVulnerabilitieswithCodePropertyGraphs.pdf