Initial repo seeding

AGENT_RULES.md

@@ -0,0 +1,53 @@
+# Agent Rules
+
+## Purpose
+
+This document defines how AI coding and writing agents may assist within `whynot-control`.
+
+## General Principle
+
+Agents may help clarify, structure, draft, compare, and analyze prototype ideas. They must not silently turn experiments into product commitments.
+
+## Allowed Agent Activities
+
+Agents may:
+
+- draft prototype cards;
+- classify ideas by lifecycle stage;
+- propose smallest useful tests;
+- summarize feedback;
+- draft signal records;
+- compare prototype candidates;
+- propose beta plans;
+- identify promotion targets;
+- prepare structured tasks for Helix or Coulomb;
+- improve wording and structure.
+
+## Requires Human Approval
+
+Agents must request approval before:
+
+- promoting a prototype to productization;
+- marking an idea as commercially validated;
+- creating public-facing claims;
+- proposing paid beta or investment mechanics;
+- contacting external users or communities;
+- changing activation level;
+- creating new implementation repositories;
+- adding payment, legal, or investment language.
+
+## Forbidden
+
+Agents must not:
+
+- create artificial urgency;
+- treat all prototype ideas as products;
+- infer willingness to pay without evidence;
+- present weak signals as strong validation;
+- create legal, financial, or investment commitments;
+- publish external beta announcements without approval;
+- act on behalf of Binky, Plenitude, or any company entity externally.
+
+## Preferred Output Style
+
+Agent outputs should be concise, evidence-oriented, explicit about uncertainty, and careful to separate idea, hypothesis, signal, and decision.

BETA_MODEL.md

@@ -0,0 +1,41 @@
+# Beta Model
+
+## Purpose
+
+This document defines how `whynot` uses closed betas and early access experiments.
+
+## Beta Principles
+
+- Keep betas small.
+- Be explicit about what is being tested.
+- Do not promise production maturity.
+- Capture feedback in a structured way.
+- Avoid payment or investment mechanics unless Binky and Plenitude are ready for the legal/commercial implications.
+
+## Beta Types
+
+| Type | Purpose |
+|---|---|
+| Conversation Beta | Test concept in discussion |
+| Concierge Beta | Deliver value manually before automation |
+| Prototype Beta | Let users interact with a rough implementation |
+| Community Beta | Test whether a group wants to gather around a topic |
+| Offer Beta | Test whether a service/package has buyer interest |
+
+## Beta Entry Criteria
+
+A beta should have:
+
+- a named prototype;
+- a target audience;
+- a clear learning question;
+- a feedback capture method;
+- a defined end condition.
+
+## Beta Exit Outcomes
+
+- Promote.
+- Iterate.
+- Park.
+- Reject.
+- Convert to offer exploration.

DECISIONS.md

@@ -0,0 +1,38 @@
+# Decisions
+
+## Open Decisions
+
+### DEC-001 — Confirm shortened organization name
+
+The organization name has been shortened from `whywhynot` to `whynot`.
+
+Status: accepted  
+Date: YYYY-MM-DD  
+
+Rationale:
+
+`whynot` is shorter, easier to use in repo names, and still preserves the curious spirit of the original concept.
+
+---
+
+### DEC-002 — Confirm activation level
+
+Should `whynot` remain A1 Incubating until the first prototype candidates are reviewed?
+
+Current proposal:
+
+- `whynot`: A1 Incubating
+
+Status: open
+
+---
+
+### DEC-003 — Confirm promotion targets
+
+Should the initial promotion targets be Helix, Coulomb, Sloppers, Plenitude, Binky, and Tegwick?
+
+Status: open
+
+## Resolved Decisions
+
+See DEC-001.

INTENT.md

@@ -0,0 +1,56 @@
+# INTENT
+
+## Purpose
+
+`whynot-control` exists to serve as the control repository for the `whynot` organization: a prototype, feedback, and market-signal space for discovering the weird and the useful.
+
+It provides a structured home for early concepts, experiments, closed betas, usability probes, and weak signals from potential users before ideas are promoted into full production or commercial publication.
+
+## Primary Utility
+
+The repository helps the user:
+
+- capture unusual but potentially useful ideas;
+- distinguish curiosity from commitment;
+- shape rough ideas into testable prototypes;
+- collect early feedback and market signals;
+- run closed beta concepts in a controlled way;
+- identify which ideas should move toward Helix, Coulomb, Sloppers, Plenitude, Binky, or Tegwick;
+- prevent premature productization.
+
+## Strategic Role
+
+`whynot` acts as the early validation and signal-capture layer in the broader landscape.
+
+It sits between raw ideation and serious product development. It allows ideas to be tested with low pressure, low cost, and explicit learning goals before they become implementation commitments.
+
+## Relationship to Other Organizations
+
+- `tegwick` provides personal control and decision hygiene.
+- `binky` provides the company and commercial/legal vehicle.
+- `helix` provides the production path for serious product implementation.
+- `coulomb` may receive validated knowledge-exploration concepts.
+- `sloppers` may provide community context for prototype discussion and beta participation.
+- `plenitude` may commercialize validated offers or services.
+
+## Operating Principle
+
+A prototype is a question made tangible.
+
+The purpose of a prototype is not to prove that an idea is brilliant. The purpose is to learn what is actually useful, desirable, feasible, or irrelevant.
+
+## Initial Scope
+
+The initial scope is to establish a lightweight but reliable structure for:
+
+- prototype intake;
+- idea classification;
+- market-signal capture;
+- feedback loops;
+- closed beta preparation;
+- early investment and validation notes;
+- promotion criteria for ideas that should move into productization.
+
+## Out of Scope
+
+This repository is not the main implementation home for production products, live customer systems, payment infrastructure, legal investment offerings, or public community operations.

MARKET_SIGNAL.md

@@ -0,0 +1,36 @@
+# Market Signal
+
+## Purpose
+
+This document defines how `whynot` records and interprets early signals from potential users, collaborators, customers, or investors.
+
+## Signal Principles
+
+- Signals are evidence, not vibes.
+- Weak signals are useful if clearly labeled.
+- Contradictory signals should be preserved.
+- A signal should be connected to a prototype, audience, or hypothesis.
+- Lack of signal is also information.
+
+## Signal Strength
+
+| Level | Name | Meaning |
+|---|---|---|
+| S0 | No Signal | No observable interest or usefulness |
+| S1 | Weak Signal | Some curiosity, comments, or informal interest |
+| S2 | Medium Signal | Repeated interest, specific feedback, or trial use |
+| S3 | Strong Signal | Users take action, return, refer, contribute, or ask for pricing |
+| S4 | Commercial Signal | Users pay, pre-order, commit budget, or request procurement path |
+
+## Signal Record Format
+
+Use `templates/signal-record.md`.
+
+## Signal Review Questions
+
+- Who produced the signal?
+- What did they actually do?
+- What did they merely say?
+- Was there cost, effort, risk, or commitment involved?
+- Does the signal point toward a specific product, offer, or community need?
+- Does the signal justify another experiment?

OPERATING_MODEL.md

@@ -0,0 +1,56 @@
+# Operating Model
+
+## Purpose
+
+This operating model defines how `whynot-control` is used to explore prototypes, collect feedback, and identify market signals without creating premature commitments.
+
+## Core Rules
+
+### 1. Prototypes are questions
+
+Each prototype should express a question about usefulness, desirability, feasibility, or willingness to pay.
+
+### 2. Signal beats enthusiasm
+
+An idea should not be promoted only because it is exciting. It should show some kind of signal.
+
+### 3. Low-cost learning first
+
+Before committing to production, prefer sketches, mockups, demos, landing pages, conversations, and small experiments.
+
+### 4. Closed beta before broad launch
+
+If an idea needs real users, use controlled participation before public exposure.
+
+### 5. Promotion requires criteria
+
+A prototype should move to Helix, Coulomb, Sloppers, Plenitude, Binky, or Tegwick only when explicit promotion criteria are met.
+
+## Work Classes
+
+| Class | Meaning |
+|---|---|
+| Raw Idea | Captured but not structured |
+| Prototype Candidate | Worth shaping into a test |
+| Experiment | Has a learning question and method |
+| Signal | Evidence from users, behavior, feedback, or willingness to pay |
+| Beta | Controlled test with selected users |
+| Promotion Candidate | May deserve productization |
+| Parked | Interesting but inactive |
+| Rejected | Intentionally not pursued |
+
+## Prototype Lifecycle
+
+```text
+Raw Idea
+  → Prototype Candidate
+  → Experiment
+  → Signal Review
+  → Park / Iterate / Promote / Reject
+```
+
+## Burnout Guardrail
+
+A prototype can be interesting and still be parked.
+
+`whynot` exists to reduce uncertainty, not to create more obligations.

PROTOTYPE_PIPELINE.md

@@ -0,0 +1,98 @@
+# Prototype Pipeline
+
+## Purpose
+
+The prototype pipeline defines how ideas move from loose capture to structured learning and possible promotion.
+
+## Stage 0 — Raw Capture
+
+Capture ideas without judging them immediately.
+
+Location:
+
+- `inbox/`
+- rough notes
+- conversations
+- sketches
+
+Done when the idea is saved somewhere and no longer needs to be held in memory.
+
+## Stage 1 — Triage
+
+Decide whether an idea deserves a prototype card.
+
+Questions:
+
+- What is the idea?
+- Who might care?
+- What problem, desire, curiosity, or opportunity does it address?
+- What is the smallest way to test it?
+- Is there an obvious reason to park it?
+
+Outcomes:
+
+- Create prototype card.
+- Park.
+- Merge with another idea.
+- Reject.
+
+## Stage 2 — Prototype Card
+
+Turn the idea into a structured prototype candidate.
+
+Required fields:
+
+- Name.
+- One-line pitch.
+- Target user or audience.
+- Learning question.
+- Smallest useful test.
+- Expected signal.
+- Promotion target if successful.
+
+Location:
+
+- `prototypes/`
+
+## Stage 3 — Experiment
+
+Test the idea with minimal cost.
+
+Possible experiment types:
+
+- Concept note.
+- Landing page.
+- Clickable mockup.
+- CLI/demo script.
+- Wizard-of-Oz process.
+- Manual concierge test.
+- Closed conversation.
+- Zulip discussion.
+- Private beta.
+- Paid pre-order test, only when legally and commercially safe.
+
+## Stage 4 — Signal Review
+
+Evaluate what was learned.
+
+| Signal Type | Examples |
+|---|---|
+| Interest | People ask for more, subscribe, volunteer, comment |
+| Usefulness | People use it to solve something real |
+| Retention | People return after first exposure |
+| Referral | People tell others |
+| Payment | People pay, pre-order, or ask for pricing |
+| Contribution | People offer work, content, code, or feedback |
+| Strategic Fit | It strengthens Helix, Coulomb, Sloppers, Plenitude, or Binky |
+
+## Stage 5 — Decision
+
+Possible decisions:
+
+- Park.
+- Iterate.
+- Promote.
+- Reject.
+- Merge into another initiative.
+
+Promotion requires an explicit decision record in `DECISIONS.md`.

README.md

@@ -0,0 +1,20 @@
+# whynot-control
+
+Control repository for the `whynot` organization.
+
+`whynot` is the prototype and market-signal space for discovering the weird and the useful. It exists to capture early ideas, test usefulness, collect feedback, run closed betas, and identify signals that may later justify productization through Helix, Coulomb, Sloppers, Plenitude, or Binky.
+
+## Initial Use
+
+1. Read `INTENT.md`.
+2. Review `SCOPE.md`.
+3. Use `PROTOTYPE_PIPELINE.md` to classify ideas.
+4. Capture loose ideas in `inbox/`.
+5. Create prototype cards only for ideas that deserve structured exploration.
+6. Promote only validated candidates toward Helix, Coulomb, Sloppers, Plenitude, or Binky.
+
+## Core Principle
+
+A prototype is a question made tangible.
+
+A prototype does not become a product merely because it is interesting.

SCOPE.md

@@ -0,0 +1,48 @@
+# SCOPE
+
+## Current Reality
+
+`whynot-control` is the control repository for organizing prototype exploration and early market-signal capture.
+
+It currently serves as a place to:
+
+- collect prototype ideas;
+- define intake and triage;
+- hold prototype cards;
+- record signals and feedback;
+- prepare closed beta concepts;
+- define promotion criteria;
+- prevent experiments from becoming unmanaged obligations.
+
+## In Scope
+
+- Prototype idea capture.
+- Prototype classification.
+- Early user feedback notes.
+- Market-signal tracking.
+- Closed beta planning.
+- Experiment records.
+- Promotion recommendations.
+- Agent-assisted drafting and analysis.
+
+## Out of Scope
+
+- Production implementation.
+- Long-term product maintenance.
+- Payment processing.
+- Legal investment documentation.
+- Public launch operations.
+- Binding financial, legal, or tax conclusions.
+
+## Adjacent Areas
+
+- `helix`: implementation and intent-to-product production path.
+- `coulomb`: idea and knowledge exploration product surface.
+- `sloppers`: community and discussion hub.
+- `plenitude`: commercial store and offer hub.
+- `binky`: company vehicle and business/legal control.
+- `tegwick`: personal operating control.
+
+## Scope Guardrail
+
+`whynot-control` explores and validates. It does not absorb all product development.

TASKS.md

@@ -0,0 +1,63 @@
+# Tasks
+
+## Active
+
+### WNO-001 — Create `whynot-control` repository
+
+Create the initial repository in the `whynot` Gitea organization.
+
+Status: open  
+Class: commitment  
+Area: whynot  
+Activation: A1  
+
+### WNO-002 — Add initial control documents
+
+Add the core documents:
+
+- `README.md`
+- `INTENT.md`
+- `SCOPE.md`
+- `OPERATING_MODEL.md`
+- `PROTOTYPE_PIPELINE.md`
+- `MARKET_SIGNAL.md`
+- `BETA_MODEL.md`
+- `WORKPLAN.md`
+- `TASKS.md`
+- `DECISIONS.md`
+- `AGENT_RULES.md`
+
+Status: open  
+Class: commitment  
+Area: whynot  
+Activation: A1  
+
+### WNO-003 — Add starter templates
+
+Add templates for prototype cards, experiment records, signal records, beta plans, promotion decisions, and agent tasks.
+
+Status: open  
+Class: commitment  
+Area: whynot  
+Activation: A1  
+
+### WNO-004 — Seed first prototype candidates
+
+Identify 3–7 prototype candidates and create initial cards.
+
+Status: open  
+Class: option  
+Area: whynot  
+Activation: A1  
+
+## Waiting
+
+None yet.
+
+## Options
+
+- Add a landing-page experiment template.
+- Add a Zulip discussion experiment template.
+- Add a feedback interview script.
+- Add a lightweight scoring rubric.
+- Connect prototype promotion to Helix issue templates.

WORKPLAN.md

@@ -0,0 +1,91 @@
+# Workplan
+
+## Goal
+
+Establish `whynot-control` as the control repository for prototype exploration, market-signal capture, and early validation.
+
+## Phase 0 — Create the Repository
+
+### Objective
+
+Create the initial repo structure and seed the core documents.
+
+### Tasks
+
+- Create `whynot-control` in the `whynot` Gitea organization.
+- Add core documents.
+- Create `inbox/`, `prototypes/`, `signals/`, `betas/`, `offers/`, `templates/`, and `agent-tasks/`.
+
+### Done When
+
+The repository exists and provides a first usable control surface for prototype exploration.
+
+## Phase 1 — Establish Intake
+
+Create a reliable way to capture and triage ideas.
+
+Tasks:
+
+- Define intake rules.
+- Add the prototype card template.
+- Add the signal record template.
+- Add the experiment record template.
+- Add the beta plan template.
+- Define when an idea becomes a prototype candidate.
+
+## Phase 2 — Seed Initial Prototype Candidates
+
+Create the first small set of prototype cards.
+
+Tasks:
+
+- Identify 3–7 candidate ideas.
+- Write a prototype card for each.
+- Assign lifecycle stage.
+- Assign likely promotion target.
+- Define smallest useful test.
+
+## Phase 3 — Define Signal Capture
+
+Make feedback and market signal visible.
+
+Tasks:
+
+- Define signal strength scale.
+- Create first signal records.
+- Connect signals to prototype cards.
+- Identify weak vs strong evidence.
+
+## Phase 4 — Prepare Closed Beta Model
+
+Create a controlled path for early users and feedback.
+
+Tasks:
+
+- Define beta types.
+- Define beta entry criteria.
+- Define beta exit outcomes.
+- Create a first beta plan template.
+
+## Phase 5 — Define Promotion Criteria
+
+Prevent premature productization while enabling strong ideas to move forward.
+
+Tasks:
+
+- Define promotion criteria for Helix.
+- Define promotion criteria for Coulomb.
+- Define promotion criteria for Sloppers.
+- Define promotion criteria for Plenitude.
+- Define when Binky must be involved.
+
+## Phase 6 — Connect to Tegwick Landscape
+
+Ensure `whynot` remains aligned with the broader project landscape.
+
+Tasks:
+
+- Add a reference from `tegwick-control`.
+- Confirm activation level.
+- Document dependencies.
+- Create initial review rhythm.

agent-tasks/seed-whynot-control.md

@@ -0,0 +1,47 @@
+# Agent Task: Seed whynot-control
+
+## Goal
+
+Create the initial `whynot-control` repository structure and populate the first control documents from the provided draft material.
+
+## Context
+
+`whynot-control` is the control repository for the `whynot` organization, formerly sketched as `whywhynot`.
+
+The organization exists to explore prototypes, discover the weird and the useful, capture market signal, and prepare closed beta or early validation paths.
+
+## Allowed Changes
+
+The agent may:
+
+- create Markdown files;
+- create folders;
+- add initial documents;
+- improve formatting;
+- fix obvious typos;
+- keep the structure lightweight;
+- preserve the shortened organization name `whynot`.
+
+## Forbidden Changes
+
+The agent must not:
+
+- rename the organization back to `whywhynot`;
+- create implementation repositories;
+- convert prototype ideas into products;
+- create public beta announcements;
+- create paid offers;
+- add legal, tax, investment, or payment claims;
+- expand the task list beyond the initial setup unless asked.
+
+## Expected Output
+
+A repository containing the core control documents, folders, templates, and initial agent task prompt.
+
+## Human Approval Required For
+
+- changing activation levels;
+- promoting prototypes;
+- creating product repos;
+- publishing external-facing material;
+- creating paid beta or investment mechanics.

betas/README.md

@@ -0,0 +1,5 @@
+# Betas
+
+Closed beta plans and beta review notes. Use `templates/beta-plan.md`.
+
+A beta should have a clear learning question, entry criteria, and exit outcome.

inbox/README.md

@@ -0,0 +1,5 @@
+# Inbox
+
+Temporary capture for rough ideas, weird observations, user comments, market hints, and product fragments.
+
+Capture is not commitment.

offers/README.md

@@ -0,0 +1,5 @@
+# Offers
+
+Early offer sketches. Offer sketches are not commercial commitments.
+
+No offer becomes public or paid without explicit review through Binky and Plenitude.

prototypes/README.md

@@ -0,0 +1,5 @@
+# Prototypes
+
+Structured prototype cards. Use `templates/prototype-card.md`.
+
+A prototype card should define a learning question and the smallest useful test.

prototypes/example-prototype-card.md

@@ -0,0 +1,53 @@
+# Prototype: Example Prototype
+
+## One-Line Pitch
+
+A placeholder example showing how prototype cards should be structured.
+
+## Stage
+
+Prototype Candidate
+
+## Target User or Audience
+
+Potential early users, collaborators, or customers.
+
+## Problem / Desire / Curiosity
+
+This placeholder should be replaced with a concrete problem, desire, curiosity, or opportunity.
+
+## Learning Question
+
+What would we need to learn to know whether this idea deserves another step?
+
+## Smallest Useful Test
+
+Create a one-page concept note and ask three relevant people for feedback.
+
+## Expected Signal
+
+At least one person asks for a concrete next step, gives specific use-case feedback, or identifies a realistic context where the idea would matter.
+
+## Signal Strength
+
+S0
+
+## Promotion Target
+
+None yet
+
+## Risks
+
+The idea may seem interesting without being useful.
+
+## Agentic Suitability
+
+Agents may help turn rough notes into a sharper prototype card.
+
+## Next Action
+
+Replace this example with a real candidate or delete it after the first real prototype cards exist.
+
+## Notes
+
+Example only.

signals/README.md

@@ -0,0 +1,5 @@
+# Signals
+
+Market-signal and feedback records. Use `templates/signal-record.md`.
+
+A signal is evidence. Record what happened, who did it, and how strong the evidence is.

templates/agent-task.md

@@ -0,0 +1,25 @@
+# Agent Task: {{title}}
+
+## Goal
+What should the agent accomplish?
+
+## Context
+Relevant background.
+
+## Inputs
+Files, documents, repos, or notes the agent should use.
+
+## Allowed Changes
+What the agent may change.
+
+## Forbidden Changes
+What the agent must not change.
+
+## Expected Output
+What the agent should produce.
+
+## Acceptance Criteria
+How to know the task is done.
+
+## Human Approval Required For
+Any areas where the agent must stop and ask.

templates/beta-plan.md

@@ -0,0 +1,31 @@
+# Beta Plan: {{name}}
+
+## Related Prototype
+Link or name.
+
+## Beta Type
+Conversation Beta / Concierge Beta / Prototype Beta / Community Beta / Offer Beta
+
+## Learning Question
+What should this beta teach us?
+
+## Target Participants
+Who should participate?
+
+## Entry Criteria
+What must be true before the beta starts?
+
+## Feedback Method
+How will feedback be collected?
+
+## Boundaries
+What is explicitly not promised?
+
+## Duration
+Start/end or review date.
+
+## Exit Outcomes
+Promote / Iterate / Park / Reject / Convert to offer exploration
+
+## Risks
+Known risks, liabilities, or expectation issues.

templates/decision-record.md

@@ -0,0 +1,25 @@
+# Decision: {{title}}
+
+## Status
+Open / Accepted / Rejected / Superseded
+
+## Date
+YYYY-MM-DD
+
+## Context
+What situation created the need for this decision?
+
+## Options
+Describe the options.
+
+## Decision
+What was decided?
+
+## Rationale
+Why this option was chosen.
+
+## Consequences
+What follows from this decision?
+
+## Review
+When or under what condition should this decision be reviewed?

templates/experiment-record.md

@@ -0,0 +1,31 @@
+# Experiment: {{name}}
+
+## Related Prototype
+Link or name.
+
+## Learning Question
+What are we testing?
+
+## Method
+How will the experiment be run?
+
+## Audience
+Who will participate or observe?
+
+## Success Signal
+What would count as useful positive evidence?
+
+## Failure / Null Signal
+What would count as weak, absent, or negative evidence?
+
+## Cost Limit
+Time, money, effort, or complexity limit.
+
+## Results
+What happened?
+
+## Interpretation
+What do the results mean?
+
+## Decision
+Park / Iterate / Promote / Reject / Merge

templates/promotion-decision.md

@@ -0,0 +1,28 @@
+# Promotion Decision: {{prototype}}
+
+## Status
+Open / Accepted / Rejected / Superseded
+
+## Related Prototype
+Link or name.
+
+## Current Stage
+Prototype Candidate / Experiment / Signal Review / Promotion Candidate
+
+## Evidence Summary
+What signals support promotion?
+
+## Counter-Evidence
+What signals argue against promotion?
+
+## Proposed Target
+Helix / Coulomb / Sloppers / Plenitude / Binky / Tegwick
+
+## Decision
+Promote / Do not promote / Iterate first / Park
+
+## Rationale
+Why?
+
+## Review Date
+YYYY-MM-DD

templates/prototype-card.md

@@ -0,0 +1,40 @@
+# Prototype: {{name}}
+
+## One-Line Pitch
+What is the idea in one sentence?
+
+## Stage
+Raw Idea / Prototype Candidate / Experiment / Signal Review / Promotion Candidate / Parked / Rejected
+
+## Target User or Audience
+Who might care?
+
+## Problem / Desire / Curiosity
+What need, pain, desire, weird observation, or opportunity does this address?
+
+## Learning Question
+What do we need to learn?
+
+## Smallest Useful Test
+What is the lowest-cost test that could produce useful information?
+
+## Expected Signal
+What evidence would make the idea more interesting?
+
+## Signal Strength
+S0 / S1 / S2 / S3 / S4
+
+## Promotion Target
+Helix / Coulomb / Sloppers / Plenitude / Binky / Tegwick / None yet
+
+## Risks
+What could mislead us or create cost, stress, liability, or distraction?
+
+## Agentic Suitability
+What agents may safely help with.
+
+## Next Action
+The smallest useful next move.
+
+## Notes
+Additional context.

templates/signal-record.md

@@ -0,0 +1,25 @@
+# Signal: {{title}}
+
+## Date
+YYYY-MM-DD
+
+## Related Prototype
+Link or name.
+
+## Signal Strength
+S0 No Signal / S1 Weak / S2 Medium / S3 Strong / S4 Commercial
+
+## Source
+Who or what produced the signal?
+
+## Observation
+What actually happened?
+
+## Interpretation
+What might this mean?
+
+## Caveats
+What could make this misleading?
+
+## Follow-Up
+What should be done next, if anything?