IHS 知识中心 - Projects

Why a separate knowledge center

From a knowledge feature to an independent knowledge product.

Agents need knowledge, editors maintain it, and other business systems may use the same material. I defined the knowledge center around independently governed assets: sources and corpora are prepared first, then consumers read what they need. Construction and consumption can evolve separately, and one source can support different knowledge products.

Shared sources and corpora connect four knowledge products with people, agents, and business systems. — Separate knowledge construction from its consumers to support governance and reuse.

Sources, versions, and provenance

Sources → Corpora → Knowledge models → Knowledge products.

Original materials retain their files and versions. Parsed content becomes shared corpora; knowledge products reference fixed inputs, and derived results retain their source relationships. I built the material, corpus, and knowledge workspaces and continued work on source packages, parsing status, and evidence locations, so a knowledge item can be traced back through its transformations.

Source versions pass through parsing and organization while evidence locations remain attached. — Retain a path back to specific sources after repeated transformation.

Documents, wikis, graphs, and rules

Document evidence · Wiki reading · Graph relationships · Rule conditions.

I treated documents, Wiki, graphs, and rules as distinct knowledge products. Documents locate original passages, Wiki organizes topics, graphs support relationship and path exploration, and rules express structured conditions. Each has its own consumption model while sharing source governance. A Wiki page complements the original evidence rather than replacing it.

Four knowledge forms show original passages, topic reading, graph relationships, and rule conditions. — Choose the knowledge form around the task and preserve the original evidence.

Editing and publication

Published snapshots and explicit authorization scope.

I implemented a single active publication slot and typed snapshots. Consumers switch only after a successful republication; external access is limited by credentials and effective authorization scope. Editors can continue working while consumers read a defined published version. Clinical YAML browsing keeps its separate application-artifact path without an added database-publication prerequisite.

Drafts and published snapshots are separated before authorized consumption; clinical YAML retains a separate artifact path. — Separate editing, publication, and consumption through explicit boundaries.

Reconciling sources and IDs

A source-table governance baseline dated September 15, 2026.

Eight source tables contained 88,099 original records. After 3,590 source deletions, 84,509 remained visible; 1,000 additional diagnosis entries brought the eight-domain visible total to 85,509. Classification projections produced 5,176 nodes and 81,067 definite assignments. The source-ID reconciliation recorded zero missing and zero extra IDs. Classification revisions preserved the existing business relationships. These are governance counts with distinct denominators.

A reconciliation of original records, deletions, and diagnosis additions alongside classification counts. — Keep each count attached to its source and denominator.

Current progress

Construction leadership · Leadership demonstration · Pilot and customer discussions.

I led product boundaries, implementation, and data governance. The content directory contains 44 disease packages and 352 files covering eight scenarios per package. The project has been demonstrated to leadership with positive feedback, while pilot validation and customer discussions continue. Content structure, medical review, and practical usage outcomes are evaluated separately.

Disease packages and eight-scenario files connect with product, engineering, governance, and pilot responsibilities. — Build a governable knowledge foundation and evaluate practical use through pilots.

My part

I led the knowledge center across product boundaries, frontend and backend engineering, source and corpus organization, knowledge products, publication and consumption contracts, and dictionary-data governance. The central contribution was turning knowledge capabilities spread across agent products into independently maintainable and reusable assets.

Visuals use de-identified interfaces and explanatory reconstructions. Example states, citations, and conversations illustrate the workflow. Project stages reflect the author’s current work account; source traceability, content scale, and engineering checks are distinct from clinical validation.