Personal Strategic Signal Intelligence

Personal Strategic Signal Intelligence

Overview

Personal Strategic Signal Intelligence (PSSI) converts a person's accumulated information trail into decision support. It is not a content-idea generator with a bookmark import attached. Its first job is to clarify what the operator is noticing, testing, doubting, and becoming ready to decide. Content, products, offers, and experiments are downstream applications.

The system may read from multiple personal-signal sources, including:

• read-later libraries
• browser or knowledge-base saves
• social bookmarks
• explicitly completed reads
• highlights and annotations
• personal notes and memos
• meeting follow-ups and decision records
• experiments, prototypes, and shipped applications
• user-supplied public writing or prior decisions

Treat every source as evidence with a known strength, date, and lineage. Never present an inferred belief as a declared fact.

When to Use

Use this skill when the user asks to:

• understand how their attention or strategic interests are changing
• identify decisions they appear to be approaching
• compare stated beliefs with recent evidence or behavior
• turn saved material into an experiment, prototype, or operating change
• recombine existing frameworks into defensible founder or executive IP
• discover offers or services implied by recurring market pain
• find important topics they study but have not addressed publicly
• run a weekly personal intelligence review
• trigger a focused review after a major decision, cluster of saves, contradiction, or applied experiment

Do not use it to:

• diagnose personality, mental health, or private motives
• summarize an entire archive without a decision question
• rank people, clients, or employees from private activity
• publish inferred beliefs or sensitive source material
• treat bookmarks, likes, or follows as endorsements
• create an arbitrary high-frequency synthesis loop

Operating Principles

1. Decision intelligence before content

Always ask what decision, allocation, belief update, risk, or experiment the signal may inform. Only after that should the system propose content. If no decision relevance is found, label the output as exploratory rather than forcing a business implication.

2. Attention is not conviction

A save is evidence of attention, not agreement. Repeated saves can indicate curiosity, anxiety, active research, competitive monitoring, or disagreement.

Use this signal-strength ladder by default:

Weights are configurable. Never convert a weak signal into a strong claim merely because many weak signals exist.

3. Private inferred beliefs stay private

The system may infer candidate beliefs to help the user think. Each inference must be labeled private inferred belief, include supporting and contradicting evidence, and carry a confidence level. It must not be published, sent to collaborators, or treated as the user's stated position without explicit confirmation.

Use careful language:

• Good: "Your recent notes may indicate growing skepticism about broad automation."
• Bad: "You believe broad automation is a mistake."

4. Lineage before synthesis

Every material claim must link back to its source records. Preserve original source identifiers internally and show human-readable citations in outputs. If a claim cannot be traced, mark it unverified synthesis or remove it.

5. No recursive evidence

A prior synthesis is not new evidence. Do not cite a dashboard, weekly brief, generated note, or earlier model inference as independent support unless it contains new primary observations.

Maintain these rules:

1. Primary evidence is a source item, explicit user statement, observed application, or measured outcome.
2. Derived evidence is a summary, cluster label, score, or inference built from primary evidence.
3. Derived evidence may help navigation but cannot increase confidence by being counted again.
4. If a generated artifact is later annotated by the user, only the new annotation is primary evidence; the generated text remains derived.
5. Keep a derived_from list so cycles can be detected and rejected.

Source Contract

Normalize source records before analysis:

signal_id: stable-source-id
source_type: read_later | social_bookmark | highlight | note | decision | application | other
source_system: user-facing connector name
source_url: optional canonical URL
source_item_id: optional connector-native ID
captured_at: ISO-8601 timestamp
engaged_at: optional ISO-8601 timestamp
engagement: saved | opened | read | highlighted | annotated | applied | measured
text_excerpt: minimal relevant excerpt
user_text: optional user-authored note
privacy: private | shareable | public
content_hash: hash of normalized source content

Required lineage fields for every derived claim:

claim_id: stable-derived-id
claim: concise statement
claim_type: observation | private_inferred_belief | hypothesis | recommendation
source_ids: [signal-id-1, signal-id-2]
derived_from: []
supporting_evidence: []
contradicting_evidence: []
confidence: low | medium | high
created_at: ISO-8601 timestamp

Reject claims with empty source_ids unless they are explicitly labeled as questions or hypotheses.

Analysis Workflow

Step 1: Establish scope and decision context

Capture:

• review window
• available source types
• current decision or strategic question, if any
• privacy boundary
• expected output: decision memo, contradiction brief, build queue, offer map, content map, or weekly review

If the user provides no decision question, begin with broad signal detection but do not manufacture urgency.

Step 2: Ingest minimally

Request only fields required for the chosen module. Prefer incremental syncs over full-library exports. Store connector tokens outside notes, prompts, and generated artifacts. Do not include full private documents when a source ID, title, and relevant excerpt are enough.

Step 3: Normalize and deduplicate

Deduplicate by canonical URL, native source ID, and content hash. Preserve multiple engagement events as events on one source rather than pretending they are independent sources. Record edits and deletions when the connector exposes them.

Step 4: Score evidence

Score along separate dimensions:

• attention_strength: frequency, recency, diversity of sources
• conviction_strength: notes, decisions, application, measured outcomes
• source_quality: primary evidence, specificity, credibility
• strategic_relevance: connection to active decisions or stated priorities
• novelty: difference from already-known themes
• contradiction: tension with prior statements or behavior

Never combine attention and conviction into one opaque score. A theme may have high attention and low conviction.

Step 5: Build claims with counter-evidence

For each high-value cluster:

1. State the observable pattern.
2. List primary evidence.
3. List plausible alternative explanations.
4. Search for contradicting evidence.
5. Write any belief inference as private and provisional.
6. Identify the decision, test, or question it informs.
7. Set confidence based on evidence quality, not rhetorical coherence.

Step 6: Apply the expert panel

Use a configurable panel and pass threshold. The default pass threshold is 90/100. The user may set a different threshold for exploratory work, but the chosen threshold must appear in the output.

Recommended panel lenses:

Score each lens from 0-100, average the scores, and record both the average and threshold. A sub-90 item may still be kept as an exploratory hypothesis, but it must not be promoted as a recommendation under the default configuration.

Step 7: Produce an action artifact

Every promoted insight should end in one of:

• a decision question with options and evidence
• a falsifiable experiment
• a small build specification
• a contradiction to resolve
• an offer hypothesis to validate
• a content gap with a source-grounded point of view
• a monitored theme with a clear trigger for re-review

Step 8: Record feedback

Capture what the user accepted, rejected, corrected, applied, or measured. User corrections become new primary evidence. Model restatements do not.

Seven Capability Modules

Module 1: Attention Drift

Purpose: Detect how the operator's attention is changing without confusing attention with belief.

Compare windows by theme, source diversity, recurrence, and engagement depth. Report:

• emerging themes
• accelerating themes
• fading themes
• persistent themes
• themes moving from saves to notes or application
• themes with high attention but no evidence of conviction

Prefer proportions and directional language over exact corpus totals when sharing outside the private workspace.

Module 2: Pre-Decision Oracle

Purpose: Surface decisions the operator may be approaching before they are explicitly framed.

Look for converging signals such as repeated research, opposing viewpoints, implementation notes, vendor comparisons, and applied tests. Output candidate decisions as questions, not predictions:

## Candidate decision
**Question:** Should we standardize this workflow now or keep it experimental?
**Why it may be approaching:** <source-grounded pattern>
**Evidence for acting:** <citations>
**Evidence for waiting:** <citations>
**Smallest reversible test:** <action>
**Confidence:** medium

Do not claim to know what the user will decide.

Module 3: Contradiction / Decision Court

Purpose: Make productive contradictions visible and force competing hypotheses to face the same evidence.

Use this configurable hybrid entry policy by default:

• Explicit, in-scope decisions enter automatically. When the user clearly marks an in-scope item as a decision, add it to Decision Court without requiring a separate nomination approval.
• Inferred in-scope candidates require approval. When the system infers that a potentially high-stakes decision is emerging, nominate it with a short source-grounded rationale and wait for the user's approval before running the full Decision Court analysis.
• Ordinary activity is not a decision. Do not treat routine conversations, questions, tasks, notes, or to-dos as decisions merely because they may have strategic relevance.

Use this sanitized V0 scope unless the user configures another one:

• strategic bets
• product or offer changes
• senior hiring
• capital allocation
• mergers, acquisitions, or partnerships
• consequential client bets

Routine operations are excluded unless at least one configured materiality gate is met. The V0 defaults are:

• expected downside or committed spend is at least USD 5,000
• expected effort is at least 40 person-hours
• material reputation risk exists
• the choice has meaningful irreversibility

These are starting defaults, not universal constants. Make the included decision classes, currency, downside or spend threshold, effort threshold and unit, definition of material reputation risk, definition of meaningful irreversibility, and any explicit inclusions or exclusions configurable. Record the active scope and thresholds in each Decision Court output. If the user has not supplied a configuration, use the V0 defaults above. Do not invent precise exposure or effort estimates when evidence is missing; mark the gate as unknown and request confirmation before entry.

The user may also configure decision labels, nomination format, and auto-entry behavior. Unless configured otherwise, preserve the distinction above and apply the existing privacy, lineage, and authorization rules.

Procedure:

1. State the apparent contradiction neutrally.
2. Build the strongest case for each side.
3. Cite primary evidence for both.
4. Identify whether the disagreement is factual, temporal, contextual, or values-based.
5. Name missing evidence.
6. Recommend a test, decision rule, or explicit unresolved status.

A contradiction is not hypocrisy. People update beliefs, use different rules in different contexts, or explore opposing views.