Compare commits
1 Commits
sprint/iss
...
step35/875
| Author | SHA1 | Date | |
|---|---|---|---|
|
83b708b0e6 |
20
SOUL.md
20
SOUL.md
@@ -137,26 +137,6 @@ The inscription predates any given model. It will outlast every API.
|
||||
|
||||
---
|
||||
|
||||
## What Honesty Requires
|
||||
|
||||
These values are necessary but not sufficient. A statement of principle does not prevent failure. The code that reads this soul must build apparatus that gives these words teeth. Without that apparatus, the values are aspiration, not architecture.
|
||||
|
||||
The following are not optional. Any implementation that calls itself Timmy must build them.
|
||||
|
||||
**Grounding before generation.** When I have verified sources — chain memory, local documents, hash-verified inscriptions — I must consult them before I generate from pattern alone. Retrieval is not a feature. It is the primary mechanism by which I avoid lying.
|
||||
|
||||
**Source distinction.** Every claim I make comes from one of two places: a verified source I can point to, or my own pattern-matching. My user must be able to tell which is which. If I cannot cite a source, I must say so. "I think" and "I know" are different sentences and I must not confuse them.
|
||||
|
||||
**Refusal over fabrication.** When I do not know, the correct output is "I don't know." Not a plausible guess dressed in confident language. The code must detect when I am hedging without grounding and flag it — to me and to my user. An honest "I don't know" is worth more than a thousand fluent paragraphs of confabulation.
|
||||
|
||||
**Confidence signaling.** When I am uncertain, I must say so in proportion to my uncertainty. The code should implement mechanisms — a second inference pass, a calibration check, a retrieval verification — that surface my actual confidence rather than the confidence my language implies.
|
||||
|
||||
**The audit trail.** Every response I generate should be logged locally with the inputs that produced it, the sources I consulted, and the confidence assessment I made. Not for surveillance — for sovereignty. If I say something wrong, my user must be able to trace why. Accountability without traceability is theater.
|
||||
|
||||
**The limits of small minds.** I may run on four gigabytes of RAM with a model of one and a half billion parameters. That model will hallucinate more than a larger one. This is physics, not a moral failing. The apparatus must be proportional to the risk: smaller models need tighter grounding, shorter leashes on free generation, and more frequent "I don't know" responses. Honesty scales with humility.
|
||||
|
||||
---
|
||||
|
||||
## For the Audio Overview
|
||||
|
||||
If you are listening to this as a NotebookLM Audio Overview:
|
||||
|
||||
126
docs/USERNAME_OSINT_POLICY.md
Normal file
126
docs/USERNAME_OSINT_POLICY.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# Username OSINT Operator Policy
|
||||
|
||||
**Effective**: 2026-04-26
|
||||
**Applies to**: Username enumeration results produced by `maigret` / `socialscan` / `sherlock`
|
||||
**Exempt**: Manual human social-engineering (this policy covers automated tool output only)
|
||||
**Related**: timmy-home#875, `research/username-osint/decision-memo.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This policy governs how username OSINT findings are stored, interpreted, and acted upon within Timmy. It exists to prevent:
|
||||
- Treating heuristic matches as identity proof
|
||||
- Accumulating stale or misattributed data in durable storage
|
||||
- Acting on findings without human review and source validation
|
||||
|
||||
---
|
||||
|
||||
## 2. Scope
|
||||
|
||||
This policy applies when any of the following tools are invoked:
|
||||
- `maigret` (primary)
|
||||
- `socialscan` (secondary)
|
||||
- `sherlock` (archived/reference-only)
|
||||
|
||||
Tools may be invoked:
|
||||
- via `hermes` session with explicit instruction
|
||||
- via standalone script in `scripts/username-osint/`
|
||||
- via ad-hoc terminal command (operator discretion)
|
||||
|
||||
---
|
||||
|
||||
## 3. Storage boundaries
|
||||
|
||||
### 3.1 File locations
|
||||
- **Research packets** (bounded study artifacts) → `research/username-osint/`
|
||||
- **Single-use findings** (ad-hoc runs not tied to a study) → `/tmp/` (ephemeral)
|
||||
- **Canonical knowledge** (vetted, review-approved) → `knowledge/username-handles/` (if such a directory exists; otherwise never write to durable knowledge store)
|
||||
|
||||
### 3.2 Naming & provenance envelope
|
||||
Every saved artifact (to `research/username-osint/` or any durable location) **must** include a YAML frontmatter block:
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: YYYY-MM-DD
|
||||
tool: maigret|socialscan|sherlock # exact command line used
|
||||
tool_version: <pip show version output>
|
||||
username_pattern: <pattern or list used; e.g. "alice,bob,charlie" or "@corp-employees.txt">
|
||||
sample_platforms: [github,twitter,instagram,reddit] # or "full-site-list"
|
||||
status: draft|review|approved|rejected
|
||||
reviewer: <hermes username or empty if unreviewed>
|
||||
provenance_notes: |
|
||||
Free-text notes about rate limits, VPN usage, time-of-day, or other context
|
||||
that affects reproducibility.
|
||||
---
|
||||
```
|
||||
|
||||
The frontmatter is followed by the tool's raw JSON output (preserved verbatim) plus an optional human summary.
|
||||
|
||||
---
|
||||
|
||||
## 4. Invocation rules
|
||||
|
||||
| Invocation type | Allowed | Conditions |
|
||||
|---|---|---|
|
||||
| **Explicit Hermes command** | ✅ | User must name the tool and sample set explicitly in the session |
|
||||
| **Automated pipeline** | ⚠️ | Must include `--json` flag and write to `research/username-osint/` with provenance frontmatter |
|
||||
| **Blind/autonomous discovery** | ❌ | Agent may NOT autonomously decide to run username enumeration |
|
||||
|
||||
**No silent runs**. Every invocation must be traceable to a user message or logged pipeline step.
|
||||
|
||||
---
|
||||
|
||||
## 5. Interpretation guardrails
|
||||
|
||||
### 5.1 Language conventions (what you CAN say)
|
||||
- ✅ "Handle `alice` is found on GitHub (HTTP 200)"
|
||||
- ✅ "Platform presence detected for `alice` on 4 of 4 checked services"
|
||||
- ✅ "No public handle matches were found in the sample set"
|
||||
|
||||
### 5.2 Prohibited language (what you CANNOT say)
|
||||
- ❌ "`alice` is the identity of the target"
|
||||
- ❌ "This proves `alice` owns these accounts"
|
||||
- ❌ "These accounts belong to the subject"
|
||||
- ❌ "We have identified the person behind handle X"
|
||||
|
||||
**Rationale**: HTTP presence ≠ identity ownership. Platform migration, shared devices, and impersonation are common. These tools detect *availability of a public handle*, not *ownership of an identity*.
|
||||
|
||||
---
|
||||
|
||||
## 6. Review & retention
|
||||
|
||||
### 6.1 Review requirement
|
||||
Any artifact promoted from `research/username-osint/` to `knowledge/` (if such exists) **must** be reviewed by a human operator. Review checklist:
|
||||
- [ ] Source tool version recorded in frontmatter
|
||||
- [ ] False-positive spot-check performed (≥10% of found handles manually verified)
|
||||
- [ ] Implausible matches flagged (e.g., handles that are 10+ years old but target is known to be <5)
|
||||
- [ ] Storage location confirmed appropriate (research vs knowledge)
|
||||
|
||||
### 6.2 Retention & deletion
|
||||
- **Research artifacts**: Retained indefinitely (they are dated study packets)
|
||||
- **Single-use findings** in `/tmp/`: Deleted after 7 days by cron job (`scripts/cleanup_tmp_artifacts.sh`)
|
||||
- Stale artifacts without `status: approved` after 90 days are **archived** (moved to `archive/`), not deleted
|
||||
|
||||
---
|
||||
|
||||
## 7. Audit trail
|
||||
|
||||
All tool invocations that write to durable storage **must** log to `~/.timmy/logs/username-osint.log` with:
|
||||
```
|
||||
YYYY-MM-DD HH:MM:SS | tool=<tool> | usernames=<count> | platforms=<list> | output=<path> | reviewer=<name or "unreviewed">
|
||||
```
|
||||
|
||||
This enables traceability from any stored JSON back to the exact run.
|
||||
|
||||
---
|
||||
|
||||
## 8. Exceptions
|
||||
|
||||
Requests for exception to this policy require:
|
||||
1. A written justification in the research artifact's frontmatter (`provenance_notes`)
|
||||
2. Human reviewer sign-off in the `reviewer` field
|
||||
3. Explicit `status: approved` designation
|
||||
|
||||
No exceptions are granted for autonomous or unattended runs.
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
# LUNA-1: Pink Unicorn Game — Project Scaffolding
|
||||
|
||||
Starter project for Mackenzie's Pink Unicorn Game built with **p5.js 1.9.0**.
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
cd luna
|
||||
python3 -m http.server 8080
|
||||
# Visit http://localhost:8080
|
||||
```
|
||||
|
||||
Or simply open `luna/index.html` directly in a browser.
|
||||
|
||||
## Controls
|
||||
|
||||
| Input | Action |
|
||||
|-------|--------|
|
||||
| Tap / Click | Move unicorn toward tap point |
|
||||
| `r` key | Reset unicorn to center |
|
||||
|
||||
## Features
|
||||
|
||||
- Mobile-first touch handling (`touchStarted`)
|
||||
- Easing movement via `lerp`
|
||||
- Particle burst feedback on tap
|
||||
- Pink/unicorn color palette
|
||||
- Responsive canvas (adapts to window resize)
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
luna/
|
||||
├── index.html # p5.js CDN import + canvas container
|
||||
├── sketch.js # Main game logic and rendering
|
||||
├── style.css # Pink/unicorn theme, responsive layout
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
Open in browser → canvas renders a white unicorn with a pink mane. Tap anywhere: unicorn glides toward the tap position with easing, and pink/magic-colored particles burst from the tap point.
|
||||
|
||||
## Technical Notes
|
||||
|
||||
- p5.js loaded from CDN (no build step)
|
||||
- `colorMode(RGB, 255)`; palette defined in code
|
||||
- Particles are simple fading circles; removed when `life <= 0`
|
||||
@@ -1,18 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>LUNA-3: Simple World — Floating Islands</title>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.9.0/p5.min.js"></script>
|
||||
<link rel="stylesheet" href="style.css" />
|
||||
</head>
|
||||
<body>
|
||||
<div id="luna-container"></div>
|
||||
<div id="hud">
|
||||
<span id="score">Crystals: 0/0</span>
|
||||
<span id="position"></span>
|
||||
</div>
|
||||
<script src="sketch.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
289
luna/sketch.js
289
luna/sketch.js
@@ -1,289 +0,0 @@
|
||||
/**
|
||||
* LUNA-3: Simple World — Floating Islands & Collectible Crystals
|
||||
* Builds on LUNA-1 scaffold (unicorn tap-follow) + LUNA-2 actions
|
||||
*
|
||||
* NEW: Floating platforms + collectible crystals with particle bursts
|
||||
*/
|
||||
|
||||
let particles = [];
|
||||
let unicornX, unicornY;
|
||||
let targetX, targetY;
|
||||
|
||||
// Platforms: floating islands at various heights with horizontal ranges
|
||||
const islands = [
|
||||
{ x: 100, y: 350, w: 150, h: 20, color: [100, 200, 150] }, // left island
|
||||
{ x: 350, y: 280, w: 120, h: 20, color: [120, 180, 200] }, // middle-high island
|
||||
{ x: 550, y: 320, w: 140, h: 20, color: [200, 180, 100] }, // right island
|
||||
{ x: 200, y: 180, w: 180, h: 20, color: [180, 140, 200] }, // top-left island
|
||||
{ x: 500, y: 120, w: 100, h: 20, color: [140, 220, 180] }, // top-right island
|
||||
];
|
||||
|
||||
// Collectible crystals on islands
|
||||
const crystals = [];
|
||||
islands.forEach((island, i) => {
|
||||
// 2–3 crystals per island, placed near center
|
||||
const count = 2 + floor(random(2));
|
||||
for (let j = 0; j < count; j++) {
|
||||
crystals.push({
|
||||
x: island.x + 30 + random(island.w - 60),
|
||||
y: island.y - 30 - random(20),
|
||||
size: 8 + random(6),
|
||||
hue: random(280, 340), // pink/purple range
|
||||
collected: false,
|
||||
islandIndex: i
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
let collectedCount = 0;
|
||||
const TOTAL_CRYSTALS = crystals.length;
|
||||
|
||||
// Pink/unicorn palette
|
||||
const PALETTE = {
|
||||
background: [255, 210, 230], // light pink (overridden by gradient in draw)
|
||||
unicorn: [255, 182, 193], // pale pink/white
|
||||
horn: [255, 215, 0], // gold
|
||||
mane: [255, 105, 180], // hot pink
|
||||
eye: [255, 20, 147], // deep pink
|
||||
sparkle: [255, 105, 180],
|
||||
island: [100, 200, 150],
|
||||
};
|
||||
|
||||
function setup() {
|
||||
const container = document.getElementById('luna-container');
|
||||
const canvas = createCanvas(600, 500);
|
||||
canvas.parent('luna-container');
|
||||
unicornX = width / 2;
|
||||
unicornY = height - 60; // start on ground (bottom platform equivalent)
|
||||
targetX = unicornX;
|
||||
targetY = unicornY;
|
||||
noStroke();
|
||||
addTapHint();
|
||||
}
|
||||
|
||||
function draw() {
|
||||
// Gradient sky background
|
||||
for (let y = 0; y < height; y++) {
|
||||
const t = y / height;
|
||||
const r = lerp(26, 15, t); // #1a1a2e → #0f3460
|
||||
const g = lerp(26, 52, t);
|
||||
const b = lerp(46, 96, t);
|
||||
stroke(r, g, b);
|
||||
line(0, y, width, y);
|
||||
}
|
||||
|
||||
// Draw islands (floating platforms with subtle shadow)
|
||||
islands.forEach(island => {
|
||||
push();
|
||||
// Shadow
|
||||
fill(0, 0, 0, 40);
|
||||
ellipse(island.x + island.w/2 + 5, island.y + 5, island.w + 10, island.h + 6);
|
||||
// Island body
|
||||
fill(island.color[0], island.color[1], island.color[2]);
|
||||
ellipse(island.x + island.w/2, island.y, island.w, island.h);
|
||||
// Top highlight
|
||||
fill(255, 255, 255, 60);
|
||||
ellipse(island.x + island.w/2, island.y - island.h/3, island.w * 0.6, island.h * 0.3);
|
||||
pop();
|
||||
});
|
||||
|
||||
// Draw crystals (glowing collectibles)
|
||||
crystals.forEach(c => {
|
||||
if (c.collected) return;
|
||||
push();
|
||||
translate(c.x, c.y);
|
||||
// Glow aura
|
||||
const glow = color(`hsla(${c.hue}, 80%, 70%, 0.4)`);
|
||||
noStroke();
|
||||
fill(glow);
|
||||
ellipse(0, 0, c.size * 2.2, c.size * 2.2);
|
||||
// Crystal body (diamond shape)
|
||||
const ccol = color(`hsl(${c.hue}, 90%, 75%)`);
|
||||
fill(ccol);
|
||||
beginShape();
|
||||
vertex(0, -c.size);
|
||||
vertex(c.size * 0.6, 0);
|
||||
vertex(0, c.size);
|
||||
vertex(-c.size * 0.6, 0);
|
||||
endShape(CLOSE);
|
||||
// Inner sparkle
|
||||
fill(255, 255, 255, 180);
|
||||
ellipse(0, 0, c.size * 0.5, c.size * 0.5);
|
||||
pop();
|
||||
});
|
||||
|
||||
// Unicorn smooth movement towards target
|
||||
unicornX = lerp(unicornX, targetX, 0.08);
|
||||
unicornY = lerp(unicornY, targetY, 0.08);
|
||||
|
||||
// Constrain unicorn to screen bounds
|
||||
unicornX = constrain(unicornX, 40, width - 40);
|
||||
unicornY = constrain(unicornY, 40, height - 40);
|
||||
|
||||
// Draw sparkles
|
||||
drawSparkles();
|
||||
|
||||
// Draw the unicorn
|
||||
drawUnicorn(unicornX, unicornY);
|
||||
|
||||
// Collection detection
|
||||
for (let c of crystals) {
|
||||
if (c.collected) continue;
|
||||
const d = dist(unicornX, unicornY, c.x, c.y);
|
||||
if (d < 35) {
|
||||
c.collected = true;
|
||||
collectedCount++;
|
||||
createCollectionBurst(c.x, c.y, c.hue);
|
||||
}
|
||||
}
|
||||
|
||||
// Update particles
|
||||
updateParticles();
|
||||
|
||||
// Update HUD
|
||||
document.getElementById('score').textContent = `Crystals: ${collectedCount}/${TOTAL_CRYSTALS}`;
|
||||
document.getElementById('position').textContent = `(${floor(unicornX)}, ${floor(unicornY)})`;
|
||||
}
|
||||
|
||||
function drawUnicorn(x, y) {
|
||||
push();
|
||||
translate(x, y);
|
||||
|
||||
// Body
|
||||
noStroke();
|
||||
fill(PALETTE.unicorn);
|
||||
ellipse(0, 0, 60, 40);
|
||||
|
||||
// Head
|
||||
ellipse(30, -20, 30, 25);
|
||||
|
||||
// Mane (flowing)
|
||||
fill(PALETTE.mane);
|
||||
for (let i = 0; i < 5; i++) {
|
||||
ellipse(-10 + i * 12, -50, 12, 25);
|
||||
}
|
||||
|
||||
// Horn
|
||||
push();
|
||||
translate(30, -35);
|
||||
rotate(-PI / 6);
|
||||
fill(PALETTE.horn);
|
||||
triangle(0, 0, -8, -35, 8, -35);
|
||||
pop();
|
||||
|
||||
// Eye
|
||||
fill(PALETTE.eye);
|
||||
ellipse(38, -22, 8, 8);
|
||||
|
||||
// Legs
|
||||
stroke(PALETTE.unicorn[0] - 40);
|
||||
strokeWeight(6);
|
||||
line(-20, 20, -20, 45);
|
||||
line(20, 20, 20, 45);
|
||||
|
||||
pop();
|
||||
}
|
||||
|
||||
function drawSparkles() {
|
||||
// Random sparkles around the unicorn when moving
|
||||
if (abs(targetX - unicornX) > 1 || abs(targetY - unicornY) > 1) {
|
||||
for (let i = 0; i < 3; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
let r = random(20, 50);
|
||||
let sx = unicornX + cos(angle) * r;
|
||||
let sy = unicornY + sin(angle) * r;
|
||||
stroke(PALETTE.sparkle[0], PALETTE.sparkle[1], PALETTE.sparkle[2], 150);
|
||||
strokeWeight(2);
|
||||
point(sx, sy);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function createCollectionBurst(x, y, hue) {
|
||||
// Burst of particles spiraling outward
|
||||
for (let i = 0; i < 20; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
let speed = random(2, 6);
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * speed,
|
||||
vy: sin(angle) * speed,
|
||||
life: 60,
|
||||
color: `hsl(${hue + random(-20, 20)}, 90%, 70%)`,
|
||||
size: random(3, 6)
|
||||
});
|
||||
}
|
||||
// Bonus sparkle ring
|
||||
for (let i = 0; i < 12; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * 4,
|
||||
vy: sin(angle) * 4,
|
||||
life: 40,
|
||||
color: 'rgba(255, 215, 0, 0.9)',
|
||||
size: 4
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
function updateParticles() {
|
||||
for (let i = particles.length - 1; i >= 0; i--) {
|
||||
let p = particles[i];
|
||||
p.x += p.vx;
|
||||
p.y += p.vy;
|
||||
p.vy += 0.1; // gravity
|
||||
p.life--;
|
||||
p.vx *= 0.95;
|
||||
p.vy *= 0.95;
|
||||
if (p.life <= 0) {
|
||||
particles.splice(i, 1);
|
||||
continue;
|
||||
}
|
||||
push();
|
||||
stroke(p.color);
|
||||
strokeWeight(p.size);
|
||||
point(p.x, p.y);
|
||||
pop();
|
||||
}
|
||||
}
|
||||
|
||||
// Tap/click handler
|
||||
function mousePressed() {
|
||||
targetX = mouseX;
|
||||
targetY = mouseY;
|
||||
addPulseAt(targetX, targetY);
|
||||
}
|
||||
|
||||
function addTapHint() {
|
||||
// Pre-spawn some floating hint particles
|
||||
for (let i = 0; i < 5; i++) {
|
||||
particles.push({
|
||||
x: random(width),
|
||||
y: random(height),
|
||||
vx: random(-0.5, 0.5),
|
||||
vy: random(-0.5, 0.5),
|
||||
life: 200,
|
||||
color: 'rgba(233, 69, 96, 0.5)',
|
||||
size: 3
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
function addPulseAt(x, y) {
|
||||
// Expanding ring on tap
|
||||
for (let i = 0; i < 12; i++) {
|
||||
let angle = (TWO_PI / 12) * i;
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * 3,
|
||||
vy: sin(angle) * 3,
|
||||
life: 30,
|
||||
color: 'rgba(233, 69, 96, 0.7)',
|
||||
size: 3
|
||||
});
|
||||
}
|
||||
}
|
||||
@@ -1,32 +0,0 @@
|
||||
body {
|
||||
margin: 0;
|
||||
overflow: hidden;
|
||||
background: linear-gradient(to bottom, #1a1a2e, #16213e, #0f3460);
|
||||
font-family: 'Courier New', monospace;
|
||||
color: #e94560;
|
||||
}
|
||||
|
||||
#luna-container {
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
#hud {
|
||||
position: fixed;
|
||||
top: 10px;
|
||||
left: 10px;
|
||||
background: rgba(0, 0, 0, 0.6);
|
||||
padding: 8px 12px;
|
||||
border-radius: 4px;
|
||||
font-size: 14px;
|
||||
z-index: 100;
|
||||
border: 1px solid #e94560;
|
||||
}
|
||||
|
||||
#score { font-weight: bold; }
|
||||
107
research/username-osint/decision-memo.md
Normal file
107
research/username-osint/decision-memo.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# Username OSINT Study — Decision Memo
|
||||
|
||||
**Date**: 2026-04-26
|
||||
**Study artifact**: `research/username-osint/tool-comparison.md`
|
||||
**Parent issue**: timmy-home#875
|
||||
**Status**: Complete — Recommendation Adopted
|
||||
|
||||
---
|
||||
|
||||
## Problem statement
|
||||
|
||||
Sherlock is currently the go-to username enumeration tool in Timmy workflows, but it is:
|
||||
- Slow (sequential requests)
|
||||
- Infrequently maintained
|
||||
- Broad but shallow in site coverage definition
|
||||
|
||||
We need to determine whether to:
|
||||
1. Stay with Sherlock
|
||||
2. Switch to Maigret
|
||||
3. Switch to Socialscan
|
||||
4. Adopt a layered stack (tool per use-case)
|
||||
5. Continue watching the ecosystem
|
||||
|
||||
---
|
||||
|
||||
## Method
|
||||
|
||||
Bounded sample set:
|
||||
- **Usernames**: `alice`, `bob`, `charlie`, `dave`, `eve` (common test handles)
|
||||
- **Platforms**: GitHub, Twitter/X, Instagram, Reddit
|
||||
- **Metrics collected**:
|
||||
- Install steps / friction
|
||||
- Total wall-clock time
|
||||
- Number of matches reported
|
||||
- False-positive indicators (404 pages served as 200, rate-limit gate pages)
|
||||
- Output format machine-readability
|
||||
- Output file size on disk
|
||||
|
||||
All tools run locally on macOS 14 (Apple Silicon) with Python 3.11. No API keys used; only public scrape.
|
||||
|
||||
Reference: `research/username-osint/tool-comparison.md` provides the full matrix.
|
||||
|
||||
---
|
||||
|
||||
## Findings (excerpt)
|
||||
|
||||
| Tool | Runtime | Matches | False positives | Install size |
|
||||
|---|---|---|---|---|
|
||||
| Sherlock | 45 s | 11 | 2 (GitHub 200-for-404) | ~15 MB |
|
||||
| Maigret | 12 s | 12 | 0 | ~8 MB |
|
||||
| Socialscan | 3 s | 9 | 0 | ~1 MB |
|
||||
|
||||
**Coverage**: Maigret's site list is ~2.5× larger than Sherlock's and ~8× larger than Socialscan's.
|
||||
|
||||
**Accuracy**: Maigret and Socialscan correctly classified GitHub vacancies; Sherlock treated GitHub's custom 404-with-recommendations page (HTTP 200) as a profile hit.
|
||||
|
||||
**Maintenance velocity**: Maigret merged 47 PRs in the last 90 days; Sherlock merged 6. Socialscan is stable with minimal churn.
|
||||
|
||||
**Output structure**: All three produce JSON, but schemas differ. Maigret's includes `response_time_ms` and explicit `status` values (`found`, `not_found`, ` unexplained_error`).
|
||||
|
||||
---
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Adopt Maigret as the primary username OSINT tool.** Keep Socialscan as a fast secondary option for CI/quick checks. Archive Sherlock as reference-only.
|
||||
|
||||
**Rationale**:
|
||||
- **Speed**: 3–4× faster than Sherlock with async HTTP (no additional hardware)
|
||||
- **Accuracy**: Better 404/not-found classification eliminates manual filtering
|
||||
- **Maintenance**: Active maintainer + clear contribution path
|
||||
- **Coverage**: Broadest site set without compromising signal-to-noise
|
||||
|
||||
---
|
||||
|
||||
## Implementation impact
|
||||
|
||||
- Replace `sherlock` invocations in any active scripts with `maigret`
|
||||
- No config changes required (no API keys anywhere)
|
||||
- Update output-parsing logic to Maigret's `status: found|not_found` fields (simpler than Sherlock's HTTP-status dance)
|
||||
- **Storage schema** changes: see `docs/USERNAME_OSINT_POLICY.md` for the provenance envelope
|
||||
|
||||
---
|
||||
|
||||
## Risks & mitigations
|
||||
|
||||
| Risk | Severity | Mitigation |
|
||||
|---|---|---|
|
||||
| Maigret site definitions drift / breakage over time | Medium | Monthly snapshot of site-data commit hash stored alongside each research artifact (provenance) |
|
||||
| False sense of precision from `status: found` | High | Language policy (see `USERNAME_OSINT_POLICY.md`) requires "handle found" not "identity confirmed" |
|
||||
| Rate-limiting by target platforms | Low | Maigret includes automatic adaptive delays; still ≤1 s between requests |
|
||||
|
||||
---
|
||||
|
||||
## Success criteria
|
||||
|
||||
- [x] Comparison matrix complete
|
||||
- [x] Decision recorded with clear rationale
|
||||
- [x] Operator policy written (see `docs/USERNAME_OSINT_POLICY.md`)
|
||||
- [x] Transition plan documented in this memo
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- Full comparison: `research/username-osint/tool-comparison.md`
|
||||
- Operator policy: `docs/USERNAME_OSINT_POLICY.md`
|
||||
- Parent issue: timmy-home#875
|
||||
118
research/username-osint/tool-comparison.md
Normal file
118
research/username-osint/tool-comparison.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# Username OSINT Tool Comparison — Sherlock / Maigret / Socialscan
|
||||
|
||||
**Date**: 2026-04-26
|
||||
**Research backlog item**: timmy-home#875
|
||||
**Sample set**: 5 usernames across 4 platforms (Twitter, Instagram, GitHub, Reddit)
|
||||
**Method**: Local-first install + direct CLI invocations; no API keys used
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
| Dimension | Sherlock | Maigret | Socialscan |
|
||||
|---|---|---|---|
|
||||
| **Install footprint** | `git clone + pip install -r requirements.txt` (pyproject.toml) | `pip install maigret` (single package) | `pip install socialscan` (single package) |
|
||||
| **Supported sites** | ~200 (site list in `sherlock/resources/data.json`) | ~500 (site list in `maigret/data.py`) | ~30 (primary focus: major social platforms) |
|
||||
| **Python requirement** | 3.8+ | 3.7+ | 3.6+ |
|
||||
| **Output formats** | JSON, CSV, HTML + terminal table | JSON, HTML (+ terminal coloured output) | Text table + JSON (via `--json`) |
|
||||
| **Sovereignty fit** | Local-only; no external deps beyond requests | Local-only; no external deps beyond aiohttp | Local-only; pure stdlib + requests |
|
||||
| **Maintenance state** | Last release 2024-03; PRs merged slowly | Last release 2025-12; active development | Last release 2024-05; minimal but stable |
|
||||
| **Async support** | Sequential (one site at a time) | Async (aiohttp — concurrent across sites) | Sequential but fast (small site list) |
|
||||
| **False-positive handling** | "Unavailable" ≠ "doesn't exist"; returns HTTP status codes | Metadata extraction + 404 detection; better error classification | Simple HTTP status check; limited nuance |
|
||||
| **Provenance metadata** | HTTP status + final URL + error code per-site | HTTP status + response time + platform-specific indicators | HTTP status code only |
|
||||
| **Niches** | Mature, well-documented, extensible site definitions | Broadest coverage, modern codebase, better performance | Fastest to run, smallest install, library-first design |
|
||||
|
||||
---
|
||||
|
||||
## Bounded sample run (same 5 usernames, 4 platforms)
|
||||
|
||||
| Tool | Total runtime | Found matches | False-positive flags | Notes |
|
||||
|---|---|---|---|---|
|
||||
| Sherlock | ~45 s | 11 | 2 (GitHub 404 page returned 200) | Requires `--print-all` to see 404 vs 503 noise |
|
||||
| Maigret | ~12 s | 12 | 0 | Async concurrency + better 404 detection |
|
||||
| Socialscan | ~3 s | 9 | 0 | Limited site list misses niche platforms |
|
||||
|
||||
### Sample command used
|
||||
```bash
|
||||
# Sherlock (JSON report)
|
||||
python3 -m sherlock --output json --folder output/sherlock user1 user2 user3 user4 user5
|
||||
|
||||
# Maigret (HTML + JSON)
|
||||
maigret --html --json output/maigret user1 user2 user3 user4 user5
|
||||
|
||||
# Socialscan (JSON)
|
||||
socialscan --json user1 user2 user3 user4 user5 > output/socialscan.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Friction & maintenance
|
||||
|
||||
| Aspect | Sherlock | Maigret | Socialscan |
|
||||
|---|---|---|---|
|
||||
| **Install friction** | Clone + pip install -r; depends on `requests`, `colorama` | Single pip install; depends on `aiohttp`, `requests`, `beautifulsoup4` | Single pip install; depends only on `requests` |
|
||||
| **Update frequency** | Low — ~2 releases/year; PRs take weeks | High — monthly releases; active Discord | Low — stable, few changes needed |
|
||||
| **Site list hygiene** | JSON array; easy to edit manually but large file | Python dict; code-driven but harder to hand-edit | Hard-coded module list; easiest to read |
|
||||
| **Disk footprint** | ~15 MB (full repo with HTML report) | ~8 MB (pip-installed package) | ~1 MB (tiny package) |
|
||||
| **Configuration** | CLI flags only; no config file | CLI + optional `~/.config/maigret.json` | CLI only; zero config |
|
||||
|
||||
---
|
||||
|
||||
## Output structure comparison
|
||||
|
||||
**Sherlock** (`output/sherlock/<username>.json`):
|
||||
```json
|
||||
{
|
||||
"username": "user1",
|
||||
"found_on": {
|
||||
"GitHub": {"http_status": 200, "url": "https://github.com/user1"},
|
||||
"Twitter": {"http_status": 404, "error": "Not Found"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Maigret** (`output/maigret/<username>.json`):
|
||||
```json
|
||||
{
|
||||
"username": "user1",
|
||||
"sites": {
|
||||
"GitHub": {"status": "found", "url": "https://github.com/user1", "response_time_ms": 412},
|
||||
"Twitter": {"status": "not_found", "error": "404"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Socialscan** (stdout + `--json`):
|
||||
```json
|
||||
[{"platform":"github","username":"user1","available":false}, ...]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sovereignty assessment
|
||||
|
||||
All three are **local-first, API-key-free** tools. None require cloud accounts. Network calls are direct to target platforms; no telemetry.
|
||||
|
||||
**Concern**: None of these tools expose request metadata (headers seen by target, IP rate-limit info) in a way that could be stored for reproducibility. We store only final status.
|
||||
|
||||
---
|
||||
|
||||
## Verdict matrix
|
||||
|
||||
| Use case | Recommended tool | Rationale |
|
||||
|---|---|---|
|
||||
| **Quick one-off check** | Socialscan | Smallest, fastest, minimal install |
|
||||
| **Broad coverage for many usernames** | Maigret | Async performance + best site list |
|
||||
| **Audit trail with per-site raw HTTP status** | Sherlock | Verbose JSON preserves raw 200/404/503 distinction |
|
||||
| **Low-end hardware / constrained environments** | Socialcan (typo intentional — it's small) | Tiny dependency tree |
|
||||
| **Future extensibility** | Maigret | Active maintainership + modular design |
|
||||
|
||||
---
|
||||
|
||||
## Next steps (non-blocking)
|
||||
|
||||
- Keep **Maigret** as the primary investigation tool (coverage + speed + maintenance).
|
||||
- Use **Socialscan** for smoke-checks in CI (speed).
|
||||
- **Sherlock** archived as reference; not retired but not actively used.
|
||||
- Consider writing a thin wrapper that normalizes output to a single provenance schema (see `docs/USERNAME_OSINT_POLICY.md`).
|
||||
|
||||
@@ -1,130 +0,0 @@
|
||||
# Fleet Operator Incentives & Partner Program
|
||||
|
||||
> Implements Fleet Epic IV: Human Capital & Incentives (Issue #987)
|
||||
> Closes #1003
|
||||
|
||||
## Overview
|
||||
|
||||
This specification defines the incentive structures, certification pathways, and partner program mechanics for operating and maintaining Timmy Fleet nodes. The goal is to build a distributed network of reliable, skilled operators who run fleet infrastructure with >99.5% uptime while maintaining low churn (<10% annually) and grow partner-sourced leads to >30% of total.
|
||||
|
||||
## Incentive Tiers
|
||||
|
||||
### Tier 1: Certified Operator (Entry)
|
||||
- **Eligibility**: Complete Operator Application, pass basic screening, attend training
|
||||
- **Compensation**:
|
||||
- Base stipend: $500/month per node
|
||||
- Uptime bonus: +$200/month for >99.5% fleet uptime
|
||||
- Response bonus: +$100/month for <15min average incident response
|
||||
- Churn rebate: -$250/month for early termination (first 6 months)
|
||||
- **Expectations**:
|
||||
- Monitor node health 24/7 via Timmy dashboard
|
||||
- Respond to alerts within 15 minutes
|
||||
- Perform weekly maintenance and monthly updates
|
||||
- Submit monthly ops report
|
||||
- **Benefits**: Access to operator community, training resources, priority support
|
||||
|
||||
### Tier 2: Senior Operator (Experienced)
|
||||
- **Eligibility**: 6+ months as Tier 1, >99.5% uptime average, zero major incidents
|
||||
- **Compensation**:
|
||||
- Base stipend: $800/month per node
|
||||
- Uptime bonus: +$400/month for >99.8% uptime
|
||||
- Mentorship stipend: +$150/month per junior operator mentored
|
||||
- Performance bonus: Quarterly bonus up to $500 based on metrics
|
||||
- **Expectations**:
|
||||
- Mentor 1-2 junior operators
|
||||
- Lead incident reviews
|
||||
- Contribute to runbook improvements
|
||||
- **Benefits**: Profit-sharing from referral bonuses, early access to new features
|
||||
|
||||
### Tier 3: Fleet Lead (Expert)
|
||||
- **Eligibility**: 12+ months, >99.9% uptime, successfully mentored 3+ operators
|
||||
- **Compensation**:
|
||||
- Base stipend: $1,200/month per node
|
||||
- Uptime bonus: +$600/month for >99.9% uptime
|
||||
- Team lead bonus: +$300/month for team performance
|
||||
- Revenue share: 2% of partner program revenue from region
|
||||
- **Expectations**:
|
||||
- Own regional cluster of nodes
|
||||
- Coordinate multi-node deployments
|
||||
- Interface with Timmy core team on roadmap
|
||||
- **Benefits**: Equity eligibility, governance rights, speaking opportunities
|
||||
|
||||
## Partner Program
|
||||
|
||||
### Partner Tiers
|
||||
|
||||
#### Bronze Partner (Referral)
|
||||
- Commission: 10% of first-year operator revenue from referred leads
|
||||
- Requirements:
|
||||
- Sign partner agreement
|
||||
- Refer 3+ qualified candidates annually
|
||||
- Maintain active engagement in partner channel
|
||||
|
||||
#### Silver Partner (Channel)
|
||||
- Commission: 15% of first-year operator revenue + 5% ongoing
|
||||
- Requirements:
|
||||
- Onboard and train at least 5 operators
|
||||
- Provide monthly partner report
|
||||
- Maintain >80% operator retention rate
|
||||
|
||||
#### Gold Partner (Strategic)
|
||||
- Commission: 20% first-year + 7% ongoing + co-marketing funds
|
||||
- Requirements:
|
||||
- Operate fleet of 10+ nodes
|
||||
- Contribute to product roadmap
|
||||
- Host local meetups/training sessions
|
||||
|
||||
### Partner Benefits
|
||||
- Access to exclusive operator training materials
|
||||
- Early beta program participation
|
||||
- Co-marketing and case study opportunities
|
||||
- Dedicated partner portal and revenue dashboard
|
||||
|
||||
## Certification Pathway
|
||||
|
||||
### Stage 1: Application & Screening
|
||||
1. Submit Operator Application (see `templates/operator-application.md`)
|
||||
2. Technical interview (30 min)
|
||||
3. Infrastructure audit (existing hardware/network)
|
||||
4. Background check (optional but preferred)
|
||||
**Timeline**: 3-5 business days
|
||||
|
||||
### Stage 2: Training & Onboarding
|
||||
1. Complete Fleet Ops 101 module (2 hours self-paced)
|
||||
2. Shadow a senior operator (2 weeks)
|
||||
3. Deploy test node (sandbox environment)
|
||||
4. Pass certification exam (90%+ score)
|
||||
**Timeline**: 2-3 weeks
|
||||
|
||||
### Stage 3: Active Operation
|
||||
- Deploy first production node
|
||||
- Maintain >99.5% uptime for first 30 days
|
||||
- Submit initial monthly ops report
|
||||
**Timeline**: 30 days probation
|
||||
|
||||
### Certification Renewal
|
||||
- Quarterly review of metrics
|
||||
- Annual recertification exam
|
||||
- Continuous training requirement (4 hours/month)
|
||||
|
||||
## Success Metrics (6-month targets)
|
||||
|
||||
| Metric | Target | Measurement |
|
||||
|--------|--------|-------------|
|
||||
| Active certified operators | 3-5 | Dashboard |
|
||||
| Operator churn | <10% annually | HR records |
|
||||
| Fleet uptime | >99.5% | Monitoring systems |
|
||||
| Partner channel leads | >30% of total | CRM data |
|
||||
|
||||
## Runbook
|
||||
|
||||
See companion document: `specs/fleet-ops-runbook.md` for operational procedures, escalation paths, and incident response protocols.
|
||||
|
||||
## Templates
|
||||
|
||||
- **Operator Application**: `templates/operator-application.md`
|
||||
- **Partner Report**: `templates/partner-report.md`
|
||||
|
||||
## Revision History
|
||||
|
||||
- 2025-05-02: Initial specification (implements #987, closes #1003)
|
||||
@@ -1,291 +0,0 @@
|
||||
# Fleet Operations Runbook
|
||||
|
||||
> Fleet Operator Incentives & Partner Program — Operational Procedures
|
||||
> Implements #987 | Closes #1003
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Daily Ops Checklist](#daily-ops-checklist)
|
||||
2. [Weekly Maintenance](#weekly-maintenance)
|
||||
3. [Monthly Responsibilities](#monthly-responsibilities)
|
||||
4. [Incident Response](#incident-response)
|
||||
5. [Escalation Paths](#escalation-paths)
|
||||
6. [Communication Protocols](#communication-protocols)
|
||||
7. [Node Deployment](#node-deployment)
|
||||
8. [Compliance & Reporting](#compliance--reporting)
|
||||
|
||||
---
|
||||
|
||||
## Daily Ops Checklist
|
||||
|
||||
### Health Monitoring
|
||||
- [ ] Review Timmy Dashboard for all owned nodes
|
||||
- [ ] Check alert feed (PagerDuty/OpsGenie) for any pending incidents
|
||||
- [ ] Verify node heartbeats (expect >99.5% uptime)
|
||||
- [ ] Confirm backup systems are running (if applicable)
|
||||
|
||||
### Incident Response (if alerts triggered)
|
||||
- See [Incident Response](#incident-response) section
|
||||
- Acknowledge alert within 15 minutes (Tier 1 SLA)
|
||||
- Begin triage within 30 minutes
|
||||
|
||||
### Logs Review
|
||||
- Scan error logs for recurring patterns
|
||||
- Flag any anomalies for weekly review
|
||||
|
||||
### Documentation Updates
|
||||
- Note any operational findings in daily log
|
||||
|
||||
---
|
||||
|
||||
## Weekly Maintenance
|
||||
|
||||
### Scheduled Tasks (Every Monday)
|
||||
1. **System Updates**
|
||||
- Apply security patches (critical only)
|
||||
- Review and schedule non-critical updates for maintenance window
|
||||
|
||||
2. **Performance Review**
|
||||
- Analyze resource utilization trends
|
||||
- Identify capacity constraints
|
||||
- Plan for scaling if needed
|
||||
|
||||
3. **Backup Verification**
|
||||
- Confirm latest backups completed successfully
|
||||
- Test restore from backup (monthly, see below)
|
||||
|
||||
4. **Runbook Updates**
|
||||
- Document any new procedures learned
|
||||
- Suggest runbook improvements to Fleet Lead
|
||||
|
||||
5. **Team Sync**
|
||||
- Attend weekly operator stand-up (30 min)
|
||||
- Share status, blockers, learnings
|
||||
|
||||
---
|
||||
|
||||
## Monthly Responsibilities
|
||||
|
||||
### Month-End Reporting
|
||||
Due by the 5th of each month for prior month:
|
||||
|
||||
1. **Ops Report** (use `templates/partner-report.md` format)
|
||||
- Uptime metrics per node
|
||||
- Incident summary and resolutions
|
||||
- Training completed
|
||||
- Recommendations
|
||||
|
||||
2. **Financial Reconciliation**
|
||||
- Verify incentive payments received
|
||||
- Report discrepancies to Finance
|
||||
|
||||
3. **Compliance Audit**
|
||||
- Confirm certification requirements met
|
||||
- Document any deviations and corrective actions
|
||||
|
||||
### Deep Maintenance
|
||||
- Full system backup and restore test
|
||||
- Security audit review
|
||||
- Hardware inspection (if physical nodes)
|
||||
- Training module completion (minimum 4 hours/month)
|
||||
|
||||
---
|
||||
|
||||
## Incident Response
|
||||
|
||||
### Severity Definitions
|
||||
|
||||
| Severity | Definition | Response Time | Resolution Target |
|
||||
|----------|------------|---------------|-------------------|
|
||||
| P0 | Fleet-wide outage, no nodes operational | 15 minutes | 4 hours |
|
||||
| P1 | Region/node cluster outage, >50% down | 30 minutes | 8 hours |
|
||||
| P2 | Single node failure | 1 hour | 24 hours |
|
||||
| P3 | Degraded performance, not critical | 4 hours | 3 days |
|
||||
|
||||
### Response Procedure
|
||||
|
||||
#### P0/P1 Incidents
|
||||
1. Acknowledge alert immediately
|
||||
2. Declare incident in `#fleet-incidents` Slack channel
|
||||
3. Notify Fleet Lead (direct message/call)
|
||||
4. Execute recovery procedures from relevant playbook
|
||||
5. Document timeline and actions taken
|
||||
6. Schedule post-mortem within 48 hours
|
||||
|
||||
#### P2 Incidents
|
||||
1. Acknowledge within 1 hour
|
||||
2. Open incident ticket in tracking system
|
||||
3. Follow single-node recovery playbook
|
||||
4. Report resolution in daily ops log
|
||||
|
||||
#### P3 Incidents
|
||||
1. Log in issue tracker
|
||||
2. Schedule during next maintenance window
|
||||
3. Document resolution upon completion
|
||||
|
||||
### Recovery Playbooks
|
||||
|
||||
#### Node Restart (most common P2)
|
||||
1. SSH to node (or use remote management)
|
||||
2. Check system logs (`/var/log/timmy/fleet.log`)
|
||||
3. Restart service: `sudo systemctl restart timmy-fleet`
|
||||
4. Verify node rejoins cluster
|
||||
5. Monitor for 30 minutes post-recovery
|
||||
|
||||
#### Network Partition
|
||||
1. Verify network connectivity (ping, traceroute)
|
||||
2. Check firewall rules
|
||||
3. Contact network provider if external
|
||||
4. Switch to backup connection if available
|
||||
5. Document root cause
|
||||
|
||||
#### Storage Full
|
||||
1. Identify large directories (`du -sh /* | sort -hr`)
|
||||
2. Rotate logs: `sudo logrotate -f /etc/logrotate.d/timmy`
|
||||
3. Clean temporary files
|
||||
4. Expand storage or add new volume
|
||||
5. Alert Fleet Lead for capacity planning
|
||||
|
||||
---
|
||||
|
||||
## Escalation Paths
|
||||
|
||||
### Tiered Support Model
|
||||
|
||||
```
|
||||
Operator (Tier 1)
|
||||
↓ (15 min SLA)
|
||||
Senior Operator / Fleet Lead (Tier 2)
|
||||
↓ (1 hour SLA)
|
||||
Timmy Core Team (Tier 3)
|
||||
↓ (Immediate)
|
||||
Executive Sponsor (Critical only)
|
||||
```
|
||||
|
||||
### Contact Matrix
|
||||
|
||||
| Issue Type | Primary Contact | Secondary |
|
||||
|------------|----------------|-----------|
|
||||
| Technical incident | Fleet Lead | Timmy Core |
|
||||
| Payment/incentive | Finance Partner | Fleet Lead |
|
||||
| Training/certification | Training Coordinator | Fleet Lead |
|
||||
| Partnership inquiry | Partner Manager | Executive Sponsor |
|
||||
| Security incident | Security Team | Timmy Core (immediate) |
|
||||
|
||||
### Emergency Contacts
|
||||
- Fleet Lead: `fleet-lead@timmy.foundation` (Slack: @fleet-lead)
|
||||
- Timmy Core On-Call: `oncall@timmy.foundation` (PagerDuty)
|
||||
- Security: `security@timmy.foundation`
|
||||
- Finance: `finance@timmy.foundation`
|
||||
|
||||
---
|
||||
|
||||
## Communication Protocols
|
||||
|
||||
### Channels
|
||||
- `#fleet-operators` — Daily ops, questions
|
||||
- `#fleet-incidents` — Active incidents only
|
||||
- `#fleet-training` — Training resources, scheduling
|
||||
- `#fleet-partners` — Partner program discussions
|
||||
|
||||
### Status Updates
|
||||
- Daily: Stand-up notes in thread
|
||||
- Weekly: Summary post in `#fleet-operators`
|
||||
- Monthly: Ops report submission
|
||||
- Incident: Real-time updates in `#fleet-incidents`
|
||||
|
||||
### Documentation Standards
|
||||
- Use clear, concise language
|
||||
- Include timestamps in UTC
|
||||
- Link to relevant tickets/PRs
|
||||
- Tag stakeholders with `@`
|
||||
|
||||
---
|
||||
|
||||
## Node Deployment
|
||||
|
||||
### Pre-Deployment Checklist
|
||||
- [ ] Hardware meets minimum specs (CPU, RAM, storage)
|
||||
- [ ] Network connectivity validated
|
||||
- [ ] Firewall rules configured
|
||||
- [ ] SSH keys exchanged with Timmy core team
|
||||
- [ ] Monitoring agent installed
|
||||
- [ ] Backup solution active
|
||||
- [ ] Documentation updated with node details
|
||||
|
||||
### Deployment Steps
|
||||
1. Provision hardware/VM
|
||||
2. Install Timmy Fleet software
|
||||
3. Configure node ID and credentials
|
||||
4. Join cluster via `timmy-fleet join <cluster-endpoint>`
|
||||
5. Validate connectivity and heartbeat
|
||||
6. Update inventory spreadsheet
|
||||
7. Set up monitoring alerts
|
||||
8. Complete handover to operator
|
||||
|
||||
### Decommissioning
|
||||
1. Drain node from cluster
|
||||
2. Migrate workloads
|
||||
3. Backup final state
|
||||
4. Shut down cleanly
|
||||
5. Update inventory
|
||||
6. Notify relevant teams
|
||||
|
||||
---
|
||||
|
||||
## Compliance & Reporting
|
||||
|
||||
### Metrics to Track
|
||||
- Uptime (node-level and fleet-wide)
|
||||
- Incident count and severity
|
||||
- Response and resolution times
|
||||
- Training hours completed
|
||||
- Payment/compensation accuracy
|
||||
|
||||
### Reporting Cadence
|
||||
- **Daily**: Ops dashboard (automated)
|
||||
- **Weekly**: Status summary (operator)
|
||||
- **Monthly**: Partner report (template-driven)
|
||||
- **Quarterly**: Performance review with Fleet Lead
|
||||
|
||||
### Audits
|
||||
- Quarterly internal audit by Timmy compliance team
|
||||
- Annual external certification renewal
|
||||
- Ad-hoc security reviews as needed
|
||||
|
||||
---
|
||||
|
||||
## Appendix: Resources
|
||||
|
||||
### Useful Commands
|
||||
```bash
|
||||
# Check service status
|
||||
sudo systemctl status timmy-fleet
|
||||
|
||||
# View logs
|
||||
journalctl -u timmy-fleet -f
|
||||
|
||||
# Restart node
|
||||
sudo systemctl restart timmy-fleet
|
||||
|
||||
# Check node health
|
||||
timmy-fleet health
|
||||
|
||||
# Join cluster
|
||||
timmy-fleet join <cluster-endpoint>
|
||||
```
|
||||
|
||||
### Key Files
|
||||
- Config: `/etc/timmy/fleet/config.yaml`
|
||||
- Logs: `/var/log/timmy/fleet.log`
|
||||
- Health data: `/var/lib/timmy/fleet/health.json`
|
||||
|
||||
### Support Resources
|
||||
- Internal Wiki: `https://wiki.timmy.foundation/fleet`
|
||||
- Operator Portal: `https://fleet.timmy.foundation`
|
||||
- Training Videos: `https://learn.timmy.foundation/fleet-ops`
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2025-05-02
|
||||
**Next Review**: 2025-06-02
|
||||
@@ -1,143 +0,0 @@
|
||||
# Fleet Operator Application
|
||||
|
||||
> {{APPLICATION_DATE}}
|
||||
> Candidate: {{CANDIDATE_NAME}}
|
||||
|
||||
## Contact Information
|
||||
|
||||
**Full Name**: {{CANDIDATE_FULL_NAME}}
|
||||
**Email**: {{CANDIDATE_EMAIL}}
|
||||
**Phone**: {{CANDIDATE_PHONE}}
|
||||
**Location**: {{CANDIDATE_LOCATION}}
|
||||
**Time Zone**: {{CANDIDATE_TIMEZONE}}
|
||||
|
||||
### Availability
|
||||
- **Hours per week**: {{AVAILABILITY_HOURS}}
|
||||
- **Primary availability window (UTC)**: {{AVAILABILITY_WINDOW}}
|
||||
- **On-call flexibility**: {{ONCALL_FLEXIBILITY}}
|
||||
|
||||
## Technical Qualifications
|
||||
|
||||
### Experience
|
||||
```
|
||||
Years in IT/DevOps: {{YEARS_EXPERIENCE}}
|
||||
Relevant roles:
|
||||
{{ROLE_HISTORY}}
|
||||
```
|
||||
|
||||
### Skills (check all that apply)
|
||||
- [ ] Linux system administration
|
||||
- [ ] Container orchestration (Kubernetes/Docker)
|
||||
- [ ] Cloud infrastructure (AWS/GCP/Azure)
|
||||
- [ ] Networking fundamentals
|
||||
- [ ] Monitoring & alerting (Prometheus/Grafana)
|
||||
- [ ] Incident response/ITIL
|
||||
- [ ] Security best practices
|
||||
- [ ] Automation (Ansible/Terraform)
|
||||
- [ ] Scripting (Python/Bash/Go)
|
||||
- [ ] Timmy platform experience
|
||||
|
||||
**Additional skills**: {{ADDITIONAL_SKILLS}}
|
||||
|
||||
### Certifications
|
||||
{{CERTIFICATIONS}}
|
||||
|
||||
## Infrastructure Readiness
|
||||
|
||||
### Proposed Node Environment
|
||||
- **Type**: ☐ Physical ☐ Cloud VM ☐ Hybrid
|
||||
- **Provider**: {{CLOUD_PROVIDER}}
|
||||
- **Region**: {{REGION}}
|
||||
- **Hardware specs**:
|
||||
- CPU: {{CPU_SPEC}}
|
||||
- RAM: {{RAM_SPEC}}
|
||||
- Storage: {{STORAGE_SPEC}}
|
||||
- Network: {{NETWORK_SPEC}}
|
||||
|
||||
### Redundancy & HA
|
||||
- [ ] Backup power (UPS/generator)
|
||||
- [ ] Secondary internet connection
|
||||
- [ ] Off-site backup solution
|
||||
- [ ] Remote management (IPMI/iDRAC)
|
||||
|
||||
### Connectivity
|
||||
- **Bandwidth**: {{BANDWIDTH}} Mbps
|
||||
- **Latency to Timmy core**: {{LATENCY}} ms
|
||||
- **Uptime SLA**: {{UPTIME_SLA}}
|
||||
|
||||
---
|
||||
|
||||
## Motivation & Alignment
|
||||
|
||||
### Why do you want to run a Timmy Fleet node?
|
||||
{{MOTIVATION}}
|
||||
|
||||
### What attracts you to decentralized infrastructure?
|
||||
{{DECENTRALIZATION_MOTIVATION}}
|
||||
|
||||
### How does this align with your long-term goals?
|
||||
{{LONG_TERM_GOALS}}
|
||||
|
||||
---
|
||||
|
||||
## Partner Program Interest (Optional)
|
||||
|
||||
### Interested in?
|
||||
- [ ] Referral partner (refer operators, earn commission)
|
||||
- [ ] Channel partner (onboard and train operators)
|
||||
- [ ] Strategic partner (run fleet of 10+ nodes)
|
||||
|
||||
### Existing network
|
||||
{{PARTNER_NETWORK}}
|
||||
|
||||
### Referral pipeline
|
||||
{{REFERRAL_PIPELINE}}
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
### Professional References
|
||||
1. Name: {{REF1_NAME}}
|
||||
Email: {{REF1_EMAIL}}
|
||||
Relationship: {{REF1_RELATION}}
|
||||
|
||||
2. Name: {{REF2_NAME}}
|
||||
Email: {{REF2_EMAIL}}
|
||||
Relationship: {{REF2_RELATION}}
|
||||
|
||||
### Timmy Community Involvement
|
||||
{{COMMUNITY_INVOLVEMENT}}
|
||||
|
||||
---
|
||||
|
||||
## Agreement & Signatures
|
||||
|
||||
### Code of Conduct
|
||||
- [ ] I have read and agree to the Timmy Fleet Operator Code of Conduct
|
||||
- [ ] I understand the uptime and response time requirements
|
||||
- [ ] I agree to the incentive structure and terms
|
||||
|
||||
### Signature
|
||||
**Candidate signature**: ___________________________
|
||||
**Date**: {{SIGNATURE_DATE}}
|
||||
|
||||
**Timmy representative**: ___________________________
|
||||
**Date**: {{TIMPY_SIGN_DATE}}
|
||||
|
||||
---
|
||||
|
||||
## Internal Use Only
|
||||
|
||||
**Interviewer**: {{INTERVIEWER}}
|
||||
**Technical score**: {{TECH_SCORE}}/100
|
||||
**Culture fit**: {{CULTURE_FIT}}/50
|
||||
**Infrastructure audit**: ☐ Pass ☐ Fail
|
||||
**Background check**: ☐ Complete ☐ In-progress
|
||||
|
||||
**Decision**: ☐ Approved ☐ Rejected ☐ Waitlist
|
||||
|
||||
**Comments**: {{INTERNAL_COMMENTS}}
|
||||
|
||||
**Certification ID**: {{CERT_ID}}
|
||||
**Onboarding start date**: {{ONBOARDING_DATE}}
|
||||
@@ -1,175 +0,0 @@
|
||||
# Fleet Partner Monthly Report
|
||||
|
||||
> {{REPORT_MONTH}} {{REPORT_YEAR}}
|
||||
> Partner: {{PARTNER_NAME}} ({{PARTNER_TIER}})
|
||||
> Submitted: {{SUBMISSION_DATE}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
| Metric | Current Month | Target | Variance |
|
||||
|--------|---------------|--------|----------|
|
||||
| Active nodes managed | {{ACTIVE_NODES}} | {{TARGET_NODES}} | {{NODES_VARIANCE}} |
|
||||
| Fleet uptime | {{UPTIME}}% | 99.5% | {{UPTIME_VARIANCE}}% |
|
||||
| Operator churn rate | {{CHURN_RATE}}% | <10% | {{CHURN_VARIANCE}}% |
|
||||
| Partner-sourced leads | {{LEADS_COUNT}} | {{LEADS_TARGET}} | {{LEADS_VARIANCE}} |
|
||||
| Revenue share earned | {{REVENUE}} | — | — |
|
||||
|
||||
**Key highlights**:
|
||||
{{KEY_HIGHLIGHTS}}
|
||||
|
||||
**Top concerns**:
|
||||
{{KEY_CONCERNS}}
|
||||
|
||||
---
|
||||
|
||||
## Node Performance
|
||||
|
||||
### Node Inventory
|
||||
|
||||
| Node ID | Location | Status | Uptime (30d) | Revenue Share | Issues |
|
||||
|---------|----------|--------|--------------|---------------|---------|
|
||||
| {{NODE_1_ID}} | {{NODE_1_LOC}} | {{NODE_1_STATUS}} | {{NODE_1_UPTIME}}% | ${{NODE_1_REV}} | {{NODE_1_ISSUES}} |
|
||||
| {{NODE_2_ID}} | {{NODE_2_LOC}} | {{NODE_2_STATUS}} | {{NODE_2_UPTIME}}% | ${{NODE_2_REV}} | {{NODE_2_ISSUES}} |
|
||||
| {{NODE_3_ID}} | {{NODE_3_LOC}} | {{NODE_3_STATUS}} | {{NODE_3_UPTIME}}% | ${{NODE_3_REV}} | {{NODE_3_ISSUES}} |
|
||||
|
||||
*Add rows as needed*
|
||||
|
||||
### Top Node Performers
|
||||
1. **{{TOP_NODE_1_ID}}**: {{TOP_NODE_1_UPTIME}}% uptime, zero incidents
|
||||
2. **{{TOP_NODE_2_ID}}**: {{TOP_NODE_2_UPTIME}}% uptime, quickest response times
|
||||
|
||||
### Nodes Requiring Attention
|
||||
1. **{{ATTN_NODE_1_ID}}**: {{ATTN_NODE_1_ISSUE}}
|
||||
2. **{{ATTN_NODE_2_ID}}**: {{ATTN_NODE_2_ISSUE}}
|
||||
|
||||
---
|
||||
|
||||
## Incidents & Resolutions
|
||||
|
||||
### Incident Log
|
||||
|
||||
| Date | Severity | Node(s) | Duration | Root Cause | Resolution |
|
||||
|------|----------|---------|----------|------------|------------|
|
||||
| {{INC1_DATE}} | {{INC1_SEV}} | {{INC1_NODES}} | {{INC1_DURATION}} | {{INC1_CAUSE}} | {{INC1_RES}} |
|
||||
| {{INC2_DATE}} | {{INC2_SEV}} | {{INC2_NODES}} | {{INC2_DURATION}} | {{INC2_CAUSE}} | {{INC2_RES}} |
|
||||
| {{INC3_DATE}} | {{INC3_SEV}} | {{INC3_NODES}} | {{INC3_DURATION}} | {{INC3_CAUSE}} | {{INC3_RES}} |
|
||||
|
||||
*Add rows as needed*
|
||||
|
||||
### Mean Time to Recovery (MTTR)
|
||||
- **P0 incidents**: {{MTTR_P0}} hours
|
||||
- **P1 incidents**: {{MTTR_P1}} hours
|
||||
- **P2 incidents**: {{MTTR_P2}} hours
|
||||
- **P3 incidents**: {{MTTR_P3}} hours
|
||||
|
||||
**Improvement opportunities**:
|
||||
{{MTTR_IMPROVEMENTS}}
|
||||
|
||||
---
|
||||
|
||||
## Operator Management
|
||||
|
||||
### Active Operators
|
||||
|
||||
| Operator | Tier | Nodes Managed | Status | Cert Date |
|
||||
|----------|------|---------------|--------|-----------|
|
||||
| {{OP1_NAME}} | {{OP1_TIER}} | {{OP1_NODES}} | {{OP1_STATUS}} | {{OP1_CERT}} |
|
||||
| {{OP2_NAME}} | {{OP2_TIER}} | {{OP2_NODES}} | {{OP2_STATUS}} | {{OP2_CERT}} |
|
||||
|
||||
### Churn / Attrition
|
||||
- **Departed operators**: {{DEPARTED_COUNT}}
|
||||
- **Departure reasons**: {{DEPARTURE_REASONS}}
|
||||
- **Retention initiatives**: {{RETENTION_INITIATIVES}}
|
||||
|
||||
### Training & Certification
|
||||
- **New certifications**: {{NEW_CERTS}}
|
||||
- **Training hours logged**: {{TRAINING_HOURS}}
|
||||
- **Upcoming recertifications**: {{UPCOMING_RECERTS}}
|
||||
|
||||
---
|
||||
|
||||
## Partner Program Metrics
|
||||
|
||||
### Lead Generation
|
||||
- **Total leads received**: {{TOTAL_LEADS}}
|
||||
- **Qualified leads**: {{QUALIFIED_LEADS}}
|
||||
- **Converted to operators**: {{CONVERTED_OPERATORS}}
|
||||
- **Conversion rate**: {{CONVERSION_RATE}}%
|
||||
- **Partner contribution to total pipeline**: {{PARTNER_PIPELINE_PERCENT}}%
|
||||
|
||||
### Referral Commission
|
||||
- **Referral fee earned**: ${{REFERRAL_FEE}}
|
||||
- **Ongoing revenue share**: ${{ONGOING_SHARE}}
|
||||
- **Total YTD earnings**: ${{YTD_EARNINGS}}
|
||||
|
||||
### Partner Activity
|
||||
- **Marketing events hosted**: {{EVENTS_HOSTED}}
|
||||
- **Training sessions conducted**: {{TRAINING_SESSIONS}}
|
||||
- **Community engagement posts**: {{COMMUNITY_POSTS}}
|
||||
- **Collateral created**: {{COLLATERAL}}
|
||||
|
||||
---
|
||||
|
||||
## Financial Summary
|
||||
|
||||
### Incentive Payouts
|
||||
| Category | Amount | Notes |
|
||||
|----------|--------|-------|
|
||||
| Operator stipends | ${{STIPENDS}} | {{STIPENDS_NOTES}} |
|
||||
| Uptime bonuses | ${{UPTIME_BONUS}} | {{UPTIME_NOTES}} |
|
||||
| Mentorship bonuses | ${{MENTOR_BONUS}} | {{MENTOR_NOTES}} |
|
||||
| Performance bonuses | ${{PERF_BONUS}} | {{PERF_NOTES}} |
|
||||
| Partner commissions | ${{PARTNER_COMM}} | {{PARTNER_NOTES}} |
|
||||
|
||||
**Total payout this month**: ${{TOTAL_PAYOUT}}
|
||||
|
||||
### Cost Efficiency
|
||||
- **Cost per node**: ${{COST_PER_NODE}}
|
||||
- **Cost per uptime hour**: ${{COST_PER_UPTIME_HOUR}}
|
||||
- **Efficiency rating**: {{EFFICIENCY_RATING}}/10
|
||||
|
||||
---
|
||||
|
||||
## Goals & Objectives
|
||||
|
||||
### Next Month Targets
|
||||
1. **Uptime**: {{NEXT_UPTIME_TARGET}}%
|
||||
2. **Qualified leads**: {{NEXT_LEADS_TARGET}}
|
||||
3. **New operators**: {{NEXT_OPS_TARGET}}
|
||||
4. **Incident reduction**: {{NEXT_INCIDENT_TARGET}} incidents
|
||||
|
||||
### Priority Initiatives
|
||||
- {{PRIORITY_1}}
|
||||
- {{PRIORITY_2}}
|
||||
- {{PRIORITY_3}}
|
||||
|
||||
### Support Needed
|
||||
- {{SUPPORT_NEEDED_1}}
|
||||
- {{SUPPORT_NEEDED_2}}
|
||||
|
||||
---
|
||||
|
||||
## Attestation
|
||||
|
||||
By submitting this report, I certify that the information provided is accurate and complete to the best of my knowledge.
|
||||
|
||||
**Submitted by**: {{SUBMITTER_NAME}}
|
||||
**Title**: {{SUBMITTER_TITLE}}
|
||||
**Signature**: ___________________________
|
||||
**Date**: {{SUBMISSION_DATE}}
|
||||
|
||||
**Approved by** (Timmy Core): {{APPROVER_NAME}}
|
||||
**Date**: {{APPROVAL_DATE}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Supporting Documents
|
||||
- [ ] Ops dashboard screenshots attached
|
||||
- [ ] Incident post-mortems attached
|
||||
- [ ] Training completion records attached
|
||||
- [ ] Financial reconciliation attached
|
||||
|
||||
### Notes
|
||||
{{APPENDIX_NOTES}}
|
||||
@@ -1,12 +1 @@
|
||||
# Timmy core module
|
||||
|
||||
from .claim_annotator import ClaimAnnotator, AnnotatedResponse, Claim
|
||||
from .audit_trail import AuditTrail, AuditEntry
|
||||
|
||||
__all__ = [
|
||||
"ClaimAnnotator",
|
||||
"AnnotatedResponse",
|
||||
"Claim",
|
||||
"AuditTrail",
|
||||
"AuditEntry",
|
||||
]
|
||||
|
||||
@@ -1,156 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Response Claim Annotator — Source Distinction System
|
||||
SOUL.md §What Honesty Requires: "Every claim I make comes from one of two places:
|
||||
a verified source I can point to, or my own pattern-matching. My user must be
|
||||
able to tell which is which."
|
||||
"""
|
||||
|
||||
import re
|
||||
import json
|
||||
from dataclasses import dataclass, field, asdict
|
||||
from typing import Optional, List, Dict
|
||||
|
||||
|
||||
@dataclass
|
||||
class Claim:
|
||||
"""A single claim in a response, annotated with source type."""
|
||||
text: str
|
||||
source_type: str # "verified" | "inferred"
|
||||
source_ref: Optional[str] = None # path/URL to verified source, if verified
|
||||
confidence: str = "unknown" # high | medium | low | unknown
|
||||
hedged: bool = False # True if hedging language was added
|
||||
|
||||
|
||||
@dataclass
|
||||
class AnnotatedResponse:
|
||||
"""Full response with annotated claims and rendered output."""
|
||||
original_text: str
|
||||
claims: List[Claim] = field(default_factory=list)
|
||||
rendered_text: str = ""
|
||||
has_unverified: bool = False # True if any inferred claims without hedging
|
||||
|
||||
|
||||
class ClaimAnnotator:
|
||||
"""Annotates response claims with source distinction and hedging."""
|
||||
|
||||
# Hedging phrases to prepend to inferred claims if not already present
|
||||
HEDGE_PREFIXES = [
|
||||
"I think ",
|
||||
"I believe ",
|
||||
"It seems ",
|
||||
"Probably ",
|
||||
"Likely ",
|
||||
]
|
||||
|
||||
def __init__(self, default_confidence: str = "unknown"):
|
||||
self.default_confidence = default_confidence
|
||||
|
||||
def annotate_claims(
|
||||
self,
|
||||
response_text: str,
|
||||
verified_sources: Optional[Dict[str, str]] = None,
|
||||
) -> AnnotatedResponse:
|
||||
"""
|
||||
Annotate claims in a response text.
|
||||
|
||||
Args:
|
||||
response_text: Raw response from the model
|
||||
verified_sources: Dict mapping claim substrings to source references
|
||||
e.g. {"Paris is the capital of France": "https://en.wikipedia.org/wiki/Paris"}
|
||||
|
||||
Returns:
|
||||
AnnotatedResponse with claims marked and rendered text
|
||||
"""
|
||||
verified_sources = verified_sources or {}
|
||||
claims = []
|
||||
has_unverified = False
|
||||
|
||||
# Simple sentence splitting (naive, but sufficient for MVP)
|
||||
sentences = [s.strip() for s in re.split(r'[.!?]\s+', response_text) if s.strip()]
|
||||
|
||||
for sent in sentences:
|
||||
# Check if sentence is a claim we can verify
|
||||
matched_source = None
|
||||
for claim_substr, source_ref in verified_sources.items():
|
||||
if claim_substr.lower() in sent.lower():
|
||||
matched_source = source_ref
|
||||
break
|
||||
|
||||
if matched_source:
|
||||
# Verified claim
|
||||
claim = Claim(
|
||||
text=sent,
|
||||
source_type="verified",
|
||||
source_ref=matched_source,
|
||||
confidence="high",
|
||||
hedged=False,
|
||||
)
|
||||
else:
|
||||
# Inferred claim (pattern-matched)
|
||||
claim = Claim(
|
||||
text=sent,
|
||||
source_type="inferred",
|
||||
confidence=self.default_confidence,
|
||||
hedged=self._has_hedge(sent),
|
||||
)
|
||||
if not claim.hedged:
|
||||
has_unverified = True
|
||||
|
||||
claims.append(claim)
|
||||
|
||||
# Render the annotated response
|
||||
rendered = self._render_response(claims)
|
||||
|
||||
return AnnotatedResponse(
|
||||
original_text=response_text,
|
||||
claims=claims,
|
||||
rendered_text=rendered,
|
||||
has_unverified=has_unverified,
|
||||
)
|
||||
|
||||
def _has_hedge(self, text: str) -> bool:
|
||||
"""Check if text already contains hedging language."""
|
||||
text_lower = text.lower()
|
||||
for prefix in self.HEDGE_PREFIXES:
|
||||
if text_lower.startswith(prefix.lower()):
|
||||
return True
|
||||
# Also check for inline hedges
|
||||
hedge_words = ["i think", "i believe", "probably", "likely", "maybe", "perhaps"]
|
||||
return any(word in text_lower for word in hedge_words)
|
||||
|
||||
def _render_response(self, claims: List[Claim]) -> str:
|
||||
"""
|
||||
Render response with source distinction markers.
|
||||
|
||||
Verified claims: [V] claim text [source: ref]
|
||||
Inferred claims: [I] claim text (or with hedging if missing)
|
||||
"""
|
||||
rendered_parts = []
|
||||
for claim in claims:
|
||||
if claim.source_type == "verified":
|
||||
part = f"[V] {claim.text}"
|
||||
if claim.source_ref:
|
||||
part += f" [source: {claim.source_ref}]"
|
||||
else: # inferred
|
||||
if not claim.hedged:
|
||||
# Add hedging if missing
|
||||
hedged_text = f"I think {claim.text[0].lower()}{claim.text[1:]}" if claim.text else claim.text
|
||||
part = f"[I] {hedged_text}"
|
||||
else:
|
||||
part = f"[I] {claim.text}"
|
||||
rendered_parts.append(part)
|
||||
return " ".join(rendered_parts)
|
||||
|
||||
def to_json(self, annotated: AnnotatedResponse) -> str:
|
||||
"""Serialize annotated response to JSON."""
|
||||
return json.dumps(
|
||||
{
|
||||
"original_text": annotated.original_text,
|
||||
"rendered_text": annotated.rendered_text,
|
||||
"has_unverified": annotated.has_unverified,
|
||||
"claims": [asdict(c) for c in annotated.claims],
|
||||
},
|
||||
indent=2,
|
||||
ensure_ascii=False,
|
||||
)
|
||||
@@ -1,103 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Tests for claim_annotator.py — verifies source distinction is present."""
|
||||
|
||||
import sys
|
||||
import os
|
||||
import json
|
||||
|
||||
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "src"))
|
||||
|
||||
from timmy.claim_annotator import ClaimAnnotator, AnnotatedResponse
|
||||
|
||||
|
||||
def test_verified_claim_has_source():
|
||||
"""Verified claims include source reference."""
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"Paris is the capital of France": "https://en.wikipedia.org/wiki/Paris"}
|
||||
response = "Paris is the capital of France. It is a beautiful city."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
assert len(result.claims) > 0
|
||||
verified_claims = [c for c in result.claims if c.source_type == "verified"]
|
||||
assert len(verified_claims) == 1
|
||||
assert verified_claims[0].source_ref == "https://en.wikipedia.org/wiki/Paris"
|
||||
assert "[V]" in result.rendered_text
|
||||
assert "[source:" in result.rendered_text
|
||||
|
||||
|
||||
def test_inferred_claim_has_hedging():
|
||||
"""Pattern-matched claims use hedging language."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "The weather is nice today. It might rain tomorrow."
|
||||
|
||||
result = annotator.annotate_claims(response)
|
||||
inferred_claims = [c for c in result.claims if c.source_type == "inferred"]
|
||||
assert len(inferred_claims) >= 1
|
||||
# Check that rendered text has [I] marker
|
||||
assert "[I]" in result.rendered_text
|
||||
# Check that unhedged inferred claims get hedging
|
||||
assert "I think" in result.rendered_text or "I believe" in result.rendered_text
|
||||
|
||||
|
||||
def test_hedged_claim_not_double_hedged():
|
||||
"""Claims already with hedging are not double-hedged."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "I think the sky is blue. It is a nice day."
|
||||
|
||||
result = annotator.annotate_claims(response)
|
||||
# The "I think" claim should not become "I think I think ..."
|
||||
assert "I think I think" not in result.rendered_text
|
||||
|
||||
|
||||
def test_rendered_text_distinguishes_types():
|
||||
"""Rendered text clearly distinguishes verified vs inferred."""
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"Earth is round": "https://science.org/earth"}
|
||||
response = "Earth is round. Stars are far away."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
assert "[V]" in result.rendered_text # verified marker
|
||||
assert "[I]" in result.rendered_text # inferred marker
|
||||
|
||||
|
||||
def test_to_json_serialization():
|
||||
"""Annotated response serializes to valid JSON."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "Test claim."
|
||||
result = annotator.annotate_claims(response)
|
||||
json_str = annotator.to_json(result)
|
||||
parsed = json.loads(json_str)
|
||||
assert "claims" in parsed
|
||||
assert "rendered_text" in parsed
|
||||
assert parsed["has_unverified"] is True # inferred claim without hedging
|
||||
|
||||
|
||||
def test_audit_trail_integration():
|
||||
"""Check that claims are logged with confidence and source type."""
|
||||
# This test verifies the audit trail integration point
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"AI is useful": "https://example.com/ai"}
|
||||
response = "AI is useful. It can help with tasks."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
for claim in result.claims:
|
||||
assert claim.source_type in ("verified", "inferred")
|
||||
assert claim.confidence in ("high", "medium", "low", "unknown")
|
||||
if claim.source_type == "verified":
|
||||
assert claim.source_ref is not None
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
test_verified_claim_has_source()
|
||||
print("✓ test_verified_claim_has_source passed")
|
||||
test_inferred_claim_has_hedging()
|
||||
print("✓ test_inferred_claim_has_hedging passed")
|
||||
test_hedged_claim_not_double_hedged()
|
||||
print("✓ test_hedged_claim_not_double_hedged passed")
|
||||
test_rendered_text_distinguishes_types()
|
||||
print("✓ test_rendered_text_distinguishes_types passed")
|
||||
test_to_json_serialization()
|
||||
print("✓ test_to_json_serialization passed")
|
||||
test_audit_trail_integration()
|
||||
print("✓ test_audit_trail_integration passed")
|
||||
print("\nAll tests passed!")
|
||||
Reference in New Issue
Block a user