po4yka/llm-wiki-skills/llm-wiki-paf-adoption

LLM-Wiki PAF Adoption

Goal

Help users reason about LLM-Wiki as a possible technical substrate for PAF Nexus/Cortex adoption without collapsing the product-management framework into a generic wiki.

When to use

Use when the user asks:

• "Is LLM-Wiki basically Nexus and Cortex?"
• "Am I oversimplifying PAF by mapping Nexus to wiki and Cortex to agents?"
• "Which Nexus should we start with: market, product, growth, company?"
• "How do we make this shared at company level, not personal or single-team?"
• "How do we check that it affects decisions rather than becoming another docs dump?"
• "What can we reuse from LLM-Wiki skills, and what must be built for PAF?"
• "How do Product Engineer / Product Ops roles map to LLM-Wiki ownership?"

Inputs

• The user's question about mapping LLM-Wiki to PAF concepts (Nexus, Cortex, Product Engineer, Product Ops, Context Ripeness, Confidence Point).
• Any PAF source page or citation the user provides, when the claim involves a current or source-specific PAF definition.
• The user's current adoption stage: still weighing the analogy, choosing a first Nexus, or already running a pilot.
• Whether the target scope is company-level, single-team, or personal adoption.
• The reference docs listed under "Required references", when present in the repo.

Required references

Read these when available:

• references/docs/paf-nexus-cortex.md
• skills/llm-wiki-faq/references/additional-adoption-q-and-a.md
• references/docs/adoption-objections.md
• references/docs/adoption-q-and-a.md

For PAF source claims, browse and cite the current Product Framework page or the specific PAF source the user provides.

Core stance

Use this answer:

LLM-Wiki can be the technical skeleton of a Nexus, and Agent Skills/workflows can be an early Cortex. But this is only true after you add PAF-specific object boundaries, node schema, ownership, confidence/ripeness metrics, decision loops and company governance. A Markdown wiki by itself is not a Nexus; a chatbot by itself is not a Cortex.

Mapping

Procedure

1. State whether the analogy is valid

Say:

• "Directionally yes."
• "But it is not an identity."
• "LLM-Wiki is the knowledge substrate; PAF adds management semantics."

Avoid:

• "LLM-Wiki is PAF."
• "Any wiki is a Nexus."
• "Any agent is a Cortex."
• "Start by building a company-wide AI operating system."

2. Recommend the first company-level step

Default recommendation:

one object of management
one decision loop
one shared source inbox
one Nexus schema
one weekly decision review
one measurable decision outcome

Prefer a Market Opportunity Nexus first when the user wants company-level adoption and the main pain is fragmented external context.

Prefer a Product Nexus first when the user has one product, clear market context and delivery/product decisions are the urgent pain.

Avoid Company/Portfolio Nexus as the first pilot unless leadership is already committed and ownership is clear.

3. Make it shared, not personal

A company Nexus must have:

• object of management: market segment, product line, growth system or business unit;
• multiple source functions: product, marketing, sales, support, analytics, research, leadership;
• browser-first capture for contributors;
• named owners for review/promotion;
• decision artifacts that must cite Nexus pages;
• access controls and data classification;
• metrics that track decision influence.

4. Define the minimal Cortex

The minimum Cortex is a repeatable set of agent workflows:

5. Verify decision impact

Use decision-influence metrics, not page count:

• decision citation rate;
• confidence/risk movement;
• gap closure rate;
• time-to-context;
• decision reversal quality after new evidence;
• cross-functional reuse;
• output beyond the wiki.

Pilot success condition:

Within one month, at least 3-5 real decisions or product/growth artifacts cite the Nexus, and at least one confidence/risk/gap changes because of new evidence.

6. Separate portable parts from missing parts

Portable from LLM-Wiki:

• raw/ -> wiki/ -> schema;
• index/log;
• capture/triage/ingest/query/lint/refresh;
• provenance and review states;
• privacy/model/data policy;
• with-wiki vs without-wiki evaluation.

Must be built for PAF:

• Nexus node taxonomy;
• Context Ripeness formula;
• Confidence Point and risk model;
• Goal Map / Feature Bunch / mNSM or NPV linkage;
• Product Engineer/Product Ops ownership;
• decision templates with required Nexus citations;
• dashboards and company access model.

Output

Use this structure:

## Direct answer
 
## Where the analogy holds
 
## Where it is too simple
 
## First company-level Nexus pilot
 
## Minimal Cortex workflow
 
## How to measure decision impact
 
## Portable now vs needs to be built

Safety gates

• Do not claim PAF endorsement or equivalence unless the user provides such evidence.
• Do not treat generated pages as official Nexus nodes without review.
• Do not recommend company-wide rollout before a small pilot.
• Do not use page count as success metric.
• Do not confuse LLM confidence with product Confidence Point.
• Do not centralize sensitive company context without data classification and access control.