Skip to content

Product Knowledge Network

jiale li edited this page Oct 16, 2026 · 2 revisions

Product knowledge network

Applies to the current main implementation. Acceptance scope and remaining historical-world limitations are recorded in Current acceptance.

The new /api/v1/intelligence/objects/{object_id}/network projection belongs to packages/intelligence/knowledge/network.py; HTTP transport remains in the knowledge router. Existing object, search and /graph semantics are preserved.

The graph is a bounded, bidirectional neighborhood with actual induced canonical edges. Initial API reads contain at most 40 nodes by default; the mobile client initially requests 16 for legibility. Expansion retains the original center, uses focus_id, and accepts up to 200 previously loaded IDs to discover cross edges. Evidence count and relation recency determine deterministic page order; opaque keyset cursors pin the knowledge creation revision. No whole-graph payload or inference runs.

Each accepted relation carries its actual source/target IDs, origin, qualifiers and EvidenceRefs, plus creation and supersession revision commit times. Historical accepted superseded rows remain available for local filtering within the selected subgraph. Objects created after the requested snapshot are excluded. Source publication time is not used as a knowledge creation timestamp.

This is a stored relation-lifetime playback, not a complete historical knowledge read: object labels, evidence metadata and overwritten/reactivated lifetimes are not fully versioned. Every response states that scope. Consumers must not supply this projection as an exact historical reasoning snapshot. Incident source/claim associations, where shown, remain a separate projection; they must never masquerade as canonical relations.

Focused regression coverage includes inbound relations, induced neighbor crosslinks, creation/supersession timestamps, no future nodes in pinned snapshots, evidence-priority ranking, expanded-node joins, pagination and malformed cursors.

The additive /api/v1/incidents/{incident_id}/network endpoint exposes this separate incident association projection through the same network envelope. revision_domain is incident, rather than the canonical envelope's knowledge. All displayed creation and correction coordinates use incident revisions; canonical claim creation revisions are never compared with them. The graph contains actual Incident/IncidentEvent/Evidence/ Claim nodes and optional evidence inspection / real claim-subject navigation refs. Association edges are explicitly marked origin=incident_record and projection=incident_association; source-link and event-reference records provide their authority. Event dates remain distinct from association commit timestamps.

Incident reads are capped at 200 timeline records, 200 source-link records, 200 referenced claims and 400 referenced observations. Scope truncation is disclosed in every response; remaining counts refer to that scoped projection. Missing referenced records are omitted. Stored incident corrections supersede previous event associations at their actual incident revision. Labels and referenced metadata remain current, so this is also not an exact historical reasoning snapshot.

Both projections enforce a hard 200-node response cap including existing nodes and anchors. When full, remaining neighbors are counted truthfully but no next cursor is advertised. Existing-node/anchor unions above the cap are rejected. Repository labels prefer stored display names and full repository names over canonical keys.

Clone this wiki locally