Lab / method
Knowledge Wiki Graphs
I am developing a federated Knowledge Wiki Graph practice that keeps meaning, evidence, and source custody distinct, then composes audience-specific outputs through human review.[1][2]
The practice begins with knowledge already present in people, language, artifacts, and relationships. The system helps a team make that knowledge visible, connected, and usable without claiming ownership of it.
Early research / method / consulting practice. Not a finished production SaaS, chatbot, surveillance system, AI replacement for judgment, or private archive browser.
At a glance
Three graph responsibilities, one reviewed output
Semantic graph
What the work means: projects, people, decisions, capabilities, claims, inquiries, and their relationships.
Evidence graph
Why a statement can be trusted or remains open: sources, observations, assets, citations, limitations, and provenance.
Source-custody graph
Where authoritative material is held and under what access, rights, consent, and retention conditions.
The portfolio is a selective projection from those responsibilities, composed for a particular audience and released through human review.
Start with one team pressure people can feel
For a fast-growing product and engineering team, the first proposal is a focused discovery or prototype sprint—not a company-wide knowledge platform. Begin with one practical question: can a new teammate understand what the team is building, why current choices were made, and what remains open without reconstructing that history from meetings and private messages?
- 01
Find the knowledge friction
Choose one recurring place where product rationale, decisions, open questions, or onboarding context is being lost.
- 02
Start from approved material
Use a small source set the team has deliberately cleared: for example, one meeting, one product brief, and one onboarding note.
- 03
Return usable operating memory
Produce a start-here page, decision record, open-question list, source links, and access notes that fit the team's existing work.
- 04
Test the handoff
Ask a teammate to find an answer, trace why it is there, correct it, and recognize what remains open or protected.
Proposed first engagement
A two-week discovery and prototype sprint the team can authorize
The timebox and participation plan are confirmed with the sponsor before work begins. The aim is not to install a new company-wide platform. It is to make one slipping decision trail easier to find, trust, correct, protect, and hand to the next teammate.
- People
- One sponsor, one working lead, and two or three teammates who can test whether the result helps them find and use what the team already knows.
- Source set
- Three to five approved sources around one decision trail, such as a product brief, meeting notes, an onboarding document, and the current place where open questions live.
- Jamie returns
- A knowledge-friction map, start-here page, decision record, open-question list, source and access notes, correction path, and a tested handoff.
- End decision
- The team decides to continue, revise, or stop—and leaves with a clear account of what worked, what remains uncertain, who owns the next step, and what would require new authorization.
Deliberately outside this first sprint
Indiscriminate ingestion, hidden monitoring, a private archive browser, a company-wide rollout, and continuing maintenance without a separate agreement.
What makes the pilot worth continuing
- A newcomer can find the current product rationale and open questions.
- A decision can be traced to its source and reviewed in context.
- A teammate can correct the record or keep sensitive material protected.
- The team can make a clear continue, revise, or stop decision.
These are proposed acceptance conditions, not a claim that a client engagement or company-wide implementation has occurred.
Where This Comes From
Source-Backed Team Memory and Noting.us were earlier forms of a question I keep returning to: how can a team preserve enough context to act well together without flattening disagreement, exposing protected material, or mistaking a record for permission?
The current successor is a Knowledge Wiki Graph practice. It treats each project as emerging from a changing universe of source material, working knowledge, decisions, open questions, evaluations, and reviewed outputs.
Three Graphs, One Reviewed Output
The architecture separates three responsibilities:
- Semantic graph: projects, people, decisions, capabilities, claims, inquiries, and the relationships that explain what the work means.
- Evidence graph: sources, observations, assets, citations, support, contradiction, limitation, and provenance that explain why a statement can be trusted—or why it remains open.
- Source-custody graph: the authoritative material, its location, access conditions, rights, consent, and retention responsibilities.
The portfolio is not a fourth source of truth. It is a selective projection: an audience-specific composition made from those graphs through human review.
A Federated Practice
The ecosystem is distributed across project-specific repositories because different materials need different owners, access rules, release rhythms, and forms of care. Each repository retains local authority. Stable identities and pinned revisions let selected context travel between projects without turning the packet, the receiving repository, or an automated evaluation into canonical truth.
Repository roles do not map one-to-one onto the three graph responsibilities. A public project archive, a private research collection, a photo-curation tool, a local correspondence graph, and this portfolio may each participate in more than one responsibility while preserving distinct publication boundaries.
Known, Open, Protected
Known material is public-safe or source-backed. Open material needs review, correction, or more context. Protected material is intentionally withheld because privacy, consent, law, safety, or client trust requires it.
The working sequence is:
Source custody → evidence and observations → interpretation and claims → semantic relationships → human-reviewed projection.
There is no shortcut from having access to a source to having evidence for a claim—or from having evidence to having permission to publish.
Example Deliverables
- knowledge-friction and relationship map
- source, workflow, and authority inventory
- decision and meeting-memory templates
- onboarding or “how we know what we know” starter page
- evaluation cases, correction paths, and release receipts
- privacy, access, attribution, consent, and retention notes
- a continue / revise / stop recommendation for the next iteration
A Focused Pilot Decision
The first useful engagement should address one team pressure, use a small set of approved sources, and return a compact operating memory that fits the team's existing work. It should be possible for a teammate to find an answer, trace its source, correct the record, and recognize what remains open or protected.
The pilot earns a next iteration only when the handoff helps another person onboard, understand a decision, or continue the work with less context loss. Output volume is not the measure of success.
Role Fit
The work connects technical project management, product operations, documentation architecture, AI evaluation, human review, and source-backed knowledge systems. It is early research and an operating method in development, not a finished platform or a claim of client adoption.
Earlier method
Source-Backed Team Memory remains part of the lineage
Developing a focused lab method for source-backed team memory: reviewable, human-correctable, source-linked operating memory for knowledge-heavy teams.
Worked example
One source enters; three review states remain visible
This synthetic example shows the method without exposing a private archive. The system does not force disagreement into certainty. It preserves what is supported, what needs review, and what should stay outside the public record.
Known
A public project brief records the launch date, intended audience, and approved owner of a decision.
Open
Two meeting summaries describe adoption differently, so the shared record flags the discrepancy for review.
Protected
Private transcripts, contact details, and unapproved collaborator context remain outside the public memory.
Concrete correction trace
The public record changed the portfolio
Earlier portfolio copy dated CallNYC to 2014-2015. A recovered Council hackathon announcement, the fuller CouncilStat data-release chronology, and contemporaneous Politico coverage placed the work in 2016.[4][5][6] The correction was applied to the work index, case study, and resume while the prior wording and reason remained visible in the Knowledge Wiki.
- Before
- 2014-2015
- After
- 2016
- Handoff
- One correction propagated to every public surface that carried the date.
Evaluation practice
Human review is part of the system
Completed AI Evals for Engineers & PMs with Shreya Shankar and Hamel Husain through Maven.[3] The coursework supports this lab's emphasis on error analysis, annotation, traces, retrieval quality, and reviewable failure modes.
Sources and notes
These notes preserve what each source supports and where its limits remain. See something that needs correction? Contact Jamie.
View 6 source notes
The RFC documents the three graph responsibilities and projection boundary; its exploring status is part of the evidence.
Boundary: This source does not establish a completed migration, a finished product, client adoption, permission to access or publish protected material.
The RFC documents federation, local repository authority, transport boundaries, and human release control; its proposed status is part of the evidence.
Boundary: This source does not establish a universal repository topology, automatic publication authority, a completed production deployment, client adoption.
Boundary: This source does not establish an evaluator license, instructor affiliation, employment by Maven, endorsement of Jamie's lab method.
The archived Civic Hall page preserves the embedded social post. It is not a recovered Civic Hall calendar listing or event-detail page.
Boundary: This source does not establish a recovered Civic Hall calendar listing, a dedicated event-detail page, the complete formal event title, the agenda, the participant roster.
The reporting connects Jamie to the January event, the fuller data release, and his independent development and iteration of CallNYC.
Boundary: This source does not establish CallNYC as an official Council product, CallNYC as a formal hackathon submission, CallNYC as a documented winner.
[6] Public CallNYC source repository.
The repository documents the surviving implementation of the independent, archived prototype.
Boundary: This source does not establish official Council ownership, formal hackathon submission status, current resident-service guidance.
