Knowledge Ops

Knowledge Operations (knowledge-ops)

Summary

Knowledge-ops transforms ephemeral session findings into reusable intelligence — connecting entities, tracking confidence over time, and enabling recall across engagements.

Domain: knowledge

Skill Identity

Purpose

Build and maintain structured, persistent knowledge graphs across sessions. Knowledge-ops transforms ephemeral session findings into reusable intelligence — connecting entities, tracking confidence over time, and enabling recall across engagements.

Without knowledge-ops, every session starts from zero. With it, each session builds on the last.

Core Concepts

Knowledge Unit

The atomic element of the knowledge graph. Each unit contains:

{
  "id": "KU-2026-05-001",
  "type": "finding | entity | relationship | pattern | hypothesis",
  "created": "2026-05-11",
  "updated": "2026-05-11",
  "confidence": 78,
  "tags": ["auth", "JWT", "CVE"],
  "content": "The auth service uses HS256 with a static secret in config.go:45",
  "source": "codebase-onboarding:auth-service",
  "linked_to": ["KU-2026-04-012", "KU-2026-05-003"],
  "expires": null
}

Knowledge Graph

A network of linked knowledge units. Relationships between units reveal:

• Attack chains (A → B → C = full exploit path)
• Pattern recurrence (same vuln type across multiple targets)
• Confidence evolution (a finding confirmed 3 times = higher confidence)

Knowledge Base

A collection of knowledge graphs organized by domain (target, technology, vulnerability type). Stored in the memory/ directory as markdown files with structured frontmatter.

Knowledge Types

Methodology

Phase 1: Capture

Extract knowledge units from session outputs:

• After codebase-onboarding: capture architecture map, security surfaces, confidence scores
• After deep-research: capture key findings, IOCs, CVEs, linked entities
• After social-intelligence: capture sentiment, key actors, timeline events
• After an exploitation attempt: capture what worked, what failed, and why

Phase 2: Structure

Assign type, tags, confidence, and links to each unit. Establish relationships between related units.

Phase 3: Store

Write structured units to the appropriate memory file. Follow the naming convention: memory/YYYY-MM-DD-[topic].md.

Phase 4: Retrieve

At session start, query the knowledge base for relevant units. Use tags, entity names, and linked IDs to surface prior context.

Phase 5: Maintain

Update confidence scores as findings are confirmed or refuted. Mark expired intelligence. Remove stale hypotheses that were disproven.

Confidence Model

Confidence scores represent certainty about a knowledge unit:

Confidence is not static. Update it when:

• A second source confirms a finding (+15 to +25)
• An attempt fails that should have worked (-10 to -30)
• A CVE is confirmed to affect the target (+20)
• A hypothesis is proven false (set to 0, mark archived)

Storage Format

Knowledge File Template

---
id: KU-[YYYY]-[MM]-[NNN]
type: [finding|entity|relationship|pattern|hypothesis|intelligence]
target: [target name or scope]
confidence: [0-100]
created: [YYYY-MM-DD]
updated: [YYYY-MM-DD]
tags: [tag1, tag2, tag3]
linked: [KU-ID-1, KU-ID-2]
source: [skill that produced this]
expires: [YYYY-MM-DD or null]
---

## Detail

[Full context, evidence, commands used, observed behavior]

## Connections

- **Confirms**: [what this validates]
- **Contradicts**: [what this disproves]
- **Leads to**: [next investigation or action]

## Confidence History

| Date | Score | Reason |
|------|-------|--------|
| [date] | [score] | [why this score] |

Use Cases

1. Target Intelligence Accumulation: Track everything learned about a target across multiple sessions
2. Vulnerability Pattern Tracking: Recognize when the same weakness appears in different systems
3. Cross-Engagement Intelligence: Identify recurring patterns across different targets (org-level behavior)
4. Pentest Report Preparation: Aggregate structured findings for final report generation
5. Knowledge Handoff: Pass complete context to another session or team member

Detection Methods

Knowledge Base Audit

• Document access anomalies: Bulk access to many documents in short window.
• Cross-tenant data access: User accessing documents outside their tenant.
• Vector store poisoning: Documents with embedding far from cluster centroid.
• Retrieval anomalies: Specific queries consistently retrieving same documents (backdoor signature).

SIEM Detection Rules

• Splunk SPL: index=kb sourcetype=document_access | stats dc(doc_id) by user_id | where dc > 100
• Custom KB monitoring: Anomaly detection on RAG retrieval patterns.

Defense Evasion Techniques

Knowledge Base Exfiltration Stealth

• Distribute across queries: Pace document reads; below rate limit.
• Use legitimate search: Mimic analyst search behavior; avoid bulk export patterns.
• Cache results: Avoid re-querying same documents; reduces read-count anomaly.

Vector Store Poisoning Stealth

• Match embedding distribution: Poisoned documents close to legitimate cluster centroid.
• Trigger-based backdoor: Activates only on specific query patterns.
• Cross-tenant indexing: Index poison in tenant A; affect queries from tenant B (if not isolated).

Integration

• Input from: codebase-onboarding, deep-research, social-intelligence, any skill that produces findings
• Output to: article-writing (for reports), MEMORY.md (for distilled summaries)
• Session startup: load relevant knowledge units before beginning any task
• Session end: capture all new findings into knowledge base before closing

Hacker Laws Alignment

• Law 3 (Intelligence Over Force): Accumulated knowledge makes every subsequent session more effective
• Law 8 (Learn from Every Operation): Systematically capturing what worked and what failed
• Law 9 (Systematic Over Random): Structured knowledge graph beats random memory