Buyer problem
The current Buyer DAG is intentionally a reconstructed record/Event Lineage view. Its nodes are source posts/records and its edges are inferred parent-to-child lineage links. The formal LineageWeave ontology, however, also defines heterogeneous concepts and properties such as Post, Person, CorporateEntity, our-side/counterparty person classes, mentions, affiliatedWith, coMentionedWith, entity-role relations, and SKOS broader/narrower hierarchy.
A buyer cannot currently inspect those ontology relationships as a real graph. Calling the Event Lineage DAG an ontology graph therefore overstates what the surface renders and leaves the following questions unanswered:
- Which people, organizations, teams, projects, and posts are connected?
- What typed property connects them?
- Is the relation authoritative, observed, inferred, proposed, superseded, or rejected?
- During which valid interval did the relation apply?
- Which authorized source evidence and provenance activity support it?
- Which nodes or edges were omitted by authorization or evidence limits?
PR #330 improves the existing Event Lineage renderer with direction, dates, accessible controls, scrolling, exact fused-score evidence, Storybook states, and an explicit truth boundary. This issue is a separate product capability; it must not turn #330 into a mixed lineage/ontology graph.
Product boundary
Event Lineage remains
- Post/record nodes only.
- Reconstructed parent-to-child lineage.
- Lineage depth, source dates, fused score, and later channel evidence.
- Explicitly inferred and non-causal unless separate evidence establishes otherwise.
Ontology Explorer adds
- Heterogeneous nodes: post, person, corporate entity, team, and project when those types exist in the governed catalog.
- Typed ontology/KG edges with canonical property IRI and localized label.
- Truth status, provenance, valid/system time, and source evidence.
- Bounded neighborhood traversal and evidence-first inspection.
The relational application database remains authoritative. OWL/RDF/JSON-LD is a governed projection and interoperability contract, not a second mutable source of truth.
Required data and API contract
Provide a bounded endpoint such as:
GET /api/ontology/neighborhood
with explicit query parameters for:
focus_node_type
focus_node_id
maximum_depth
maximum_nodes
maximum_edges
allowed_property_codes
knowledge_cutoff
cursor
Return typed objects rather than an arbitrary graph bag:
ontology_graph_node
- node_id
- node_type_code
- ontology_class_iri
- display_label
- truth_status_code
- valid_from
- valid_to
- recorded_at
- evidence_count
ontology_graph_edge
- edge_id
- source_node_id
- target_node_id
- property_code
- ontology_property_iri
- property_label
- truth_status_code
- valid_from
- valid_to
- recorded_at
- provenance_reference
- evidence_references
Requirements:
- Run RBAC/ABAC and source-eligibility checks before a node, edge, count, label, or path enters the response.
- Remove an edge if either endpoint is not visible.
- Do not reveal hidden-neighborhood counts through totals, truncation text, or cursor behavior.
- Reject unknown node/property types, dangling endpoints, cross-tenant references, non-finite numeric metadata, excessive traversal depth, and unbounded requests.
- Do not expose arbitrary Cypher, SPARQL UPDATE, SQL, or caller-supplied query fragments.
- Preserve deterministic ordering and stable opaque identifiers.
- Distinguish
authoritative, observed, inferred, proposed, superseded, and rejected; never promote inference because it is displayed.
- Bind historical views to
available_time <= knowledge_cutoff; current-only facts without a time contract stay out of an as-of response.
Buyer surface
Extend the existing Buyer relationship/evidence surface rather than creating a second application or misleading GNB destination.
Required behavior:
- Node type has redundant visual encoding: shape/icon plus text, never color alone.
- Edge label shows the governed property label; the canonical IRI is available in evidence details.
- Truth status and temporal validity are visible without hover-only interaction.
- Selecting a node opens its authorized evidence and offers the next valid traversal action.
- Selecting an edge opens property, provenance, validity, source evidence, and limitation details.
- A legend explains node types, edge truth status, and the distinction from Event Lineage.
- Bounded expand/collapse, search within the loaded graph, focus reset, and deterministic layout.
- Exact-value table exposes the same visible nodes/edges for keyboard, screen reader, touch, print, CSV/JSON-LD export, and audit.
- Narrow viewports use a readable alternative layout rather than shrinking the whole graph.
- Empty, partial, truncated, hidden-evidence, stale-evidence, rejected-proposal, and access-denied states name the buyer's next action.
Figma and Storybook
Use the safe LineageWeave buyer design-system file recorded in ADR 0002:
Figma File ID: 1Su3lDRmiZdcUs47t1QwIX
Create sanitized, synthetic frames before implementation for:
- desktop ontology neighborhood;
- mobile/narrow exact-value-first view;
- node evidence drawer;
- edge/provenance drawer;
- legend and filtering;
- empty, truncated, partial, denied, and stale states.
Record frame IDs in a collision-free ADR. Build reusable design-token-backed Storybook components and interaction states; no confidential source frame or production identity may enter the repository.
RED → GREEN acceptance
- A synthetic
Post -> mentions -> Person -> affiliatedWith -> CorporateEntity path round-trips through PostgreSQL and the typed API with exact IRIs and provenance.
- A SKOS broader/narrower corporate hierarchy remains distinct from OWL class subsumption.
- An inferred edge is never serialized or announced as authoritative.
- A hidden endpoint removes the edge and all count/path side channels.
- A cutoff query excludes evidence that became available later.
- Unsupported or dangling ontology terms fail closed rather than rendering an “unknown” authoritative relation.
- Keyboard users can select every visible node and edge and reach the same evidence available to pointer users.
- Screen readers receive interactive descendants; no enclosing ARIA
img hides graph controls.
- Exact-value table, print, CSV, and JSON-LD contain the same authorized visible graph.
- Layout remains deterministic for a fixed payload and does not overlap labels in the supported bounded fixture sizes.
- Storybook includes every required state and production build succeeds.
- PostgreSQL integration, frontend tests, accessibility tests, i18n consistency, security, SAST, production statement/branch coverage, and public docstrings satisfy repository gates.
Standards and doctoring
Use and cite in APA 7th format:
- RDF 1.1 Concepts and Abstract Syntax.
- RDF Schema 1.1.
- OWL 2 Web Ontology Language.
- SKOS Simple Knowledge Organization System.
- PROV-O.
- OWL-Time.
- JSON-LD 1.1.
- SHACL for projection validation where applicable.
- WCAG 2.2 for graph interaction and exact-value alternatives.
Update docs/doctoring/REFERENCES.md, docs/doctoring/STANDARD_TRACEABILITY.md, the product/technical gap baseline, architecture diagrams, Storybook inventory, and CHANGELOG in the implementation PR.
Dependency and merge gate
Buyer problem
The current Buyer DAG is intentionally a reconstructed record/Event Lineage view. Its nodes are source posts/records and its edges are inferred parent-to-child lineage links. The formal LineageWeave ontology, however, also defines heterogeneous concepts and properties such as
Post,Person,CorporateEntity, our-side/counterparty person classes,mentions,affiliatedWith,coMentionedWith, entity-role relations, and SKOS broader/narrower hierarchy.A buyer cannot currently inspect those ontology relationships as a real graph. Calling the Event Lineage DAG an ontology graph therefore overstates what the surface renders and leaves the following questions unanswered:
PR #330 improves the existing Event Lineage renderer with direction, dates, accessible controls, scrolling, exact fused-score evidence, Storybook states, and an explicit truth boundary. This issue is a separate product capability; it must not turn #330 into a mixed lineage/ontology graph.
Product boundary
Event Lineage remains
Ontology Explorer adds
The relational application database remains authoritative. OWL/RDF/JSON-LD is a governed projection and interoperability contract, not a second mutable source of truth.
Required data and API contract
Provide a bounded endpoint such as:
with explicit query parameters for:
Return typed objects rather than an arbitrary graph bag:
Requirements:
authoritative,observed,inferred,proposed,superseded, andrejected; never promote inference because it is displayed.available_time <= knowledge_cutoff; current-only facts without a time contract stay out of an as-of response.Buyer surface
Extend the existing Buyer relationship/evidence surface rather than creating a second application or misleading GNB destination.
Required behavior:
Figma and Storybook
Use the safe LineageWeave buyer design-system file recorded in ADR 0002:
Create sanitized, synthetic frames before implementation for:
Record frame IDs in a collision-free ADR. Build reusable design-token-backed Storybook components and interaction states; no confidential source frame or production identity may enter the repository.
RED → GREEN acceptance
Post -> mentions -> Person -> affiliatedWith -> CorporateEntitypath round-trips through PostgreSQL and the typed API with exact IRIs and provenance.imghides graph controls.Standards and doctoring
Use and cite in APA 7th format:
Update
docs/doctoring/REFERENCES.md,docs/doctoring/STANDARD_TRACEABILITY.md, the product/technical gap baseline, architecture diagrams, Storybook inventory, and CHANGELOG in the implementation PR.Dependency and merge gate