Product Requirements Document — Version 1.3
August 19, 2026
Product Definition
Chickadee Meerkat is an open, federated telephone reputation network that gives ordinary users simple protection, gives power users deep control, and allows communities to learn collectively from unwanted calls while leaving each person in control of who can reach them.
Most spam-call products collapse a complicated trust problem into a label:
Spam.
Spam Risk.
Potential Spam.
That is not enough.
It tells the user almost nothing about why the call was flagged, how current the information is, whether people are reporting it now, whether the number may have changed owners, whether the call resembles a known spam campaign, or how certain the system actually is.
Chickadee Meerkat replaces that model with four things:
A distributed reputation network that remembers callers, campaigns, and behavior over time.
AI-assisted risk analysis that looks for reporting patterns, spoofing indicators, campaign relationships, behavioral anomalies, and attempts to manipulate the reputation network itself.
A five-position tolerance dial that lets each user decide how much uncertainty they are willing to accept.
Progressive participation, where ordinary users get a simple product while power users and node operators can inspect and control the machinery underneath it.
Two principles define the system:
The network evaluates risk. The user decides acceptable risk.
Simple by default. Sovereign by choice.
The product is both a consumer application and an open protocol.
Anyone should be able to build a compatible client, operate a node, establish a trust community, create a regional implementation, or build a commercial service on top of the network.
The network needs persistent reputation.
It does not need persistent civil identity.
The Problem
Telephone spam persists because control over the system is badly distributed.
Carriers can suppress some unwanted traffic, but aggressive blocking creates costs for them: false positives, customer complaints, regulatory obligations, liability, and interference with legitimate high-volume callers.
The person receiving the garbage bears most of the remaining cost.
Existing consumer spam systems only partly solve this because they tend to share the same structural weaknesses:
Reputation is attached primarily to individual numbers.
Spam operations can rotate numbers and repeatedly shed reputation.
Caller classifications are opaque.
Reporting a bad call has little visible consequence.
Users have limited control over their own blocking threshold.
Old reputation can survive after a number changes owners.
Authenticated identity is often confused with trustworthy behavior.
Crowdsourced systems can be manipulated.
Numbers stored in Contacts can still be spoofed.
Operating systems can prevent an app from enforcing the user's preferred policy.
Those platform failures are often invisible.
Proprietary reputation databases cannot be independently audited.
Technically sophisticated users receive little more control than casual users.
The existing question is usually:
Is this number spam?
Chickadee Meerkat asks:
What caller, organization, or campaign does this call appear to belong to? What evidence do we have about its behavior? How good is that evidence? And does this user permit a call carrying that level of risk?
Those are three different questions:
Identity: Who appears to be calling?
Reputation: How has that caller, number, organization, or campaign behaved?
Policy: Does this user want this kind of call?
Identity verification must never automatically create trust.
Product Principles
User Sovereignty
The user decides what level of call risk is acceptable.
No institution, verified business, carrier, government agency, hospital, reputation score, or network consensus automatically overrides an explicit user policy.
Simple by Default, Sovereign by Choice
Nobody should need to understand federation, cryptography, trust graphs, or AI models to stop spam calls.
Nobody who does understand those things should be prevented from controlling them.
Progressive Complexity
Advanced capability appears when the user asks for it.
It is not dumped into the default interface.
Evidence Over Assertion
The system explains why a caller appears risky.
It does not simply pronounce judgment.
Reputation Over Blacklists
The network remembers behavior and campaigns, not merely telephone numbers.
Continuity Without Identification
A participant can build long-term reputation without revealing civil identity.
No Silent Degradation
If Android, iOS, a carrier, or another platform layer prevents Chickadee Meerkat from carrying out the user's chosen policy, the user is told.
Trust Is Earned
Users, nodes, organizations, and trust communities build reputation through behavior.
A new identity does not receive high trust simply because it exists.
Federation Without Naivety
Anyone may participate.
That does not mean everyone receives equal trust.
Nodes themselves are assumed to be potentially hostile.
Good Defaults, Not Mandatory Authority
Ordinary users receive strong default settings.
Power users can replace those defaults where technically possible.
Verification Is Not Approval
Knowing who is calling does not mean the user wants the call.
Privacy by Architecture
Personal relationship data stays local whenever possible.
Privacy is a design constraint, not a sentence buried in a privacy policy.
Adversarial by Design
Assume attackers will attempt to manipulate caller identity, reports, identities, nodes, trust relationships, campaign clustering, and AI.
Participation Does Not Require Administration
Using Chickadee Meerkat must never require running Chickadee Meerkat.
Policy Is Not Evidence
A user's decision to block a caller is not evidence that the caller is bad.
Importance Is Not Entitlement
A hospital may be important.
A government agency may be important.
A school may be important.
That does not give any of them an automatic right to make the user's phone ring.
Participation Model
Chickadee Meerkat separates ordinary use from network administration.
There are three participation levels.
Tier A — Everyday User
This is the default.
An Everyday User needs to understand only:
the five-position tolerance dial;
the three call indicators;
Report Spam;
Trusted / Not Spam;
explicit allow and block actions.
Their normal experience should be:
Install → Choose tolerance → Receive calls → See simple intelligence → Report or trust when useful
Nothing else is required.
An Everyday User does not need to understand nodes, federation, public-key cryptography, Sybil attacks, trusted rings, campaign graphs, AI weights, regional models, sponsorship, or reputation algorithms.
They still participate in the network.
Their explicit reports, corrections, and long-term reliability become evidence.
Their cryptographic identity can accumulate trust invisibly in the background.
Tier B — Power User
Power User mode is opt-in.
Power users may access:
detailed evidence;
reputation history;
caller-history graphs;
custom risk thresholds;
custom allow/block rules;
relationship controls;
regional models;
trust communities;
sponsorship;
report provenance;
campaign inspection;
advanced privacy controls;
node preferences;
appeals;
identity backup and migration;
trust-source weighting;
custom rule composition;
protocol diagnostics.
Entering Power User mode must not silently change protection.
Only deliberate policy changes by the user may do that.
Tier C — Node Operator
Node Operators participate in network infrastructure.
They may:
operate federated nodes;
validate signed reports;
analyze campaigns;
publish reputation summaries;
participate in node-to-node trust;
operate trusted rings;
identify malicious reporting clusters;
tune regional models;
inspect node health;
participate in protocol governance;
provide institutional or community reputation services.
Node administration should normally live outside the consumer application.
These tiers describe complexity and responsibility, not social rank.
Millions of ordinary observations give the network breadth. Power users and operators provide deeper analysis and governance.
Mass participation at the edge, earned expertise in the middle, distributed infrastructure at the core.
The Five-Position Tolerance Dial
The tolerance dial is the primary control for Everyday Users.
Using it must not require understanding how the reputation engine works.
Level 1 — Lockdown
Only explicitly permitted callers ring.
Where the platform permits full enforcement:
Contacts and explicit allowlist only.
No verified company, hospital, school, government agency, carrier, or other institution bypasses Lockdown automatically.
If the user says contacts only, contacts only means contacts only.
Suspected spoofing of a contact may still trigger additional warning, screening, or blocking where the platform permits it.
Level 2 — Trusted
Allows:
contacts;
explicit allowlists;
strongly trusted callers;
callers meeting the user's strict trust threshold;
verified critical-service callers where the rest of the evidence remains reassuring.
Unknown or materially uncertain callers are screened, silenced, or blocked where possible.
Identity verification may improve confidence.
It does not create automatic permission.
Level 3 — Balanced
Default mode.
Blocks or suppresses:
high-confidence spam;
abusive campaigns;
strongly suspicious calls.
Ordinary unknown callers with no substantial risk evidence are allowed.
Verified critical-service identity may count as positive evidence, but it remains one signal among many.
Level 4 — Permissive
Blocks only callers with strong evidence of abuse, fraud, or an active spam campaign.
Most unknown callers ring.
Level 5 — Open
The product primarily provides intelligence.
Calls generally ring unless explicitly blocked.
Warnings remain available.
Three-Indicator Call Intelligence
Every evaluated call exposes three independent indicators.
They are not collapsed into one unexplained spam score.
Each indicator has three states:
Green: Current evidence indicates low concern or provides positive evidence of trust.
Yellow: Evidence is incomplete, mixed, stale, or uncertain.
Red: Current evidence indicates elevated risk.
Unknown or insufficient evidence should normally be Yellow, not Green.
Indicator One — Reputation Freshness
Answers:
How current is our useful information about this caller?
Inputs may include:
most recent trusted classification;
most recent spam classification;
most recent meaningful observation;
last known ownership period;
age of current reputation data;
estimated ownership continuity.
A number heavily reported a year ago but quiet ever since should not remain permanently red because of old behavior.
Old information becomes uncertain.
Indicator Two — Spam Heat
Answers:
How much current reporting activity surrounds this caller?
Inputs may include:
reports in the previous 24 hours;
reports in the previous seven days;
report velocity;
acceleration;
number of independent reporters;
reporter credibility;
geographic spread;
coordinated-report detection.
Example:
186 recent reports
+340% against recent baseline
Spam Heat measures reporting activity.
It does not independently prove fraud or illegality.
Indicator Three — AI Risk Analysis
Answers:
What does the wider evidence suggest about this particular call?
Possible inputs include:
caller authentication;
abnormal calling time;
timezone inconsistency;
geographic inconsistency;
unusual cadence;
originating-network reputation;
number rotation;
campaign clustering;
common callback destinations;
behavioral similarity to known campaigns;
local relationship class;
recency of contact;
suspected contact spoofing;
node-derived reputation;
organizational identity;
abrupt behavioral changes.
The user can open this indicator and see human-readable reasons.
Progressive Disclosure
The incoming-call screen should contain only enough information for an immediate decision.
Example:
Freshness: Green
Spam Heat: Yellow
AI Risk: Red
Tap for details.
Expanded view:
Freshness: Recent
Spam Heat: Moderate rise
AI: High risk
Reason: Probable campaign match + weak authentication
Power User view may add:
report counts;
report velocity;
evidence age;
source classes;
campaign relationships;
trusted-ring signals;
model reason codes;
OS enforcement status;
evidence provenance.
Node Operator tools may go deeper still.
The complexity exists.
The ordinary user never has to carry it.
Accessibility
The three-indicator system must not depend on color alone.
Every state should also use at least two additional forms of communication.
Required accessibility support includes:
distinct icons or shapes;
text labels;
screen-reader descriptions;
large-text support;
high-contrast support;
sufficiently large controls;
optional haptic or sound differentiation where supported.
The UI should say:
Freshness — Green — Recent
not merely show a green dot.
Accessibility is part of the product contract.
Explainability
Every automated decision should be explainable in ordinary language.
The user should be able to see:
what Chickadee Meerkat observed;
how old the evidence is;
what came from users;
what came from network analysis;
what came from AI;
what tolerance level they selected;
what Chickadee Meerkat attempted;
what the operating system actually did.
Example:
Community: 124 recent reports
Network: Associated with 8 related numbers
AI: Probable campaign match
Your policy: Block
Result: Blocked
Preferred language includes:
reported;
frequently reported;
high risk;
suspected spoof;
unverified;
probable campaign match;
insufficient evidence;
strong authentication;
stale reputation.
Explainability requires meaningful evidence categories and reason codes.
It does not require publishing every live model weight or anti-abuse threshold.
Reference Policy
The three indicators remain separate for the user.
Enforcement cannot be vague.
A reference implementation should map evidence and tolerance into predictable behavior.
| Evidence | Lockdown | Trusted | Balanced | Permissive | Open |
|---|---|---|---|---|---|
| Green / Green / Green | Allow only if contact or allowlisted | Allow | Allow | Allow | Allow |
| Yellow / Green / Green | Block unless allowed | Screen or allow by trust rule | Allow | Allow | Allow |
| Yellow / Yellow / Yellow | Block unless allowed | Screen or block | Screen | Allow | Allow |
| Green / Red / Yellow | Block unless allowed | Block | Screen | Allow with warning | Allow with warning |
| Green / Red / Red | Block | Block | Block | Screen or block | Allow with strong warning |
| Yellow / Red / Red | Block | Block | Block | Block or screen | Allow with strong warning |
| Red / Red / Red | Block | Block | Block | Block | Allow only under explicit Open policy |
This is the reference policy, not an eternal immutable truth.
Default mappings should be versioned.
Power Users may customize them.
Reputation Beyond Telephone Numbers
Chickadee Meerkat maintains reputation for more than phone numbers.
Possible reputation objects include:
telephone number;
authenticated caller identity;
business;
originating network;
campaign;
callback destination;
reporter;
node;
trusted ring.
A new number strongly associated with a known campaign may inherit some campaign evidence.
It should not automatically inherit a final judgment.
The network remembers behavioral continuity, not merely identifiers.
Reputation Decay
Reputation must decay.
Telephone numbers are reused.
Businesses change ownership.
Campaigns end.
Users make mistakes.
Old information becomes less predictive.
Decay applies to positive and negative reputation.
Different objects may decay at different rates.
A campaign may retain reputation longer than one telephone number because the campaign represents continuing behavior while the number is disposable infrastructure.
Number Reassignment
Number reassignment is not the same thing as ordinary reputation decay.
Signals may include:
carrier or numbering data where legally available;
sudden behavioral change;
major geographic change;
multiple trusted corrections;
new verified ownership;
long inactivity followed by different behavior.
A probable reassignment should accelerate decay of the number's inherited reputation.
It should not erase the historical reputation of the old campaign.
Local Relationship Intelligence
Contact and relationship information should remain on-device whenever possible.
The phone may classify relationships into categories such as:
frequent recent contact;
recent two-way contact;
occasional contact;
dormant contact;
newly added contact;
business or service contact;
favorite or emergency contact;
unknown caller.
The network does not need to know who the contact actually is.
Use relationship metadata without requiring relationship identity.
Spoofing Detection
A match with Contacts does not establish authenticity by itself.
A call claiming to come from a known contact may be evaluated using:
authentication;
contact recency;
normal interaction pattern;
unusual calling time;
geographic inconsistency;
source history;
campaign similarity;
network reputation;
current report activity.
The UI may display:
Possible spoof of [Contact Name]
A known number and a verified caller are different things.
Persistent Pseudonymous Identity
Chickadee Meerkat may reuse the identity model developed for Clockwork Butterfly.
Conceptually:
Private key → remains with participant
Public identity → persistent network reputation
Signed action → verifiable continuity
Reputation requires continuity, not identification.
Everyday Users should not need to manage cryptographic identity during normal use.
Power Users may inspect, export, back up, or migrate it.
The system should support key revocation and migration.
Event Types
Chickadee Meerkat distinguishes reputation events from policy and enforcement events.
SPAM_REPORT
Explicit user report that a call was unwanted or abusive.
May affect reputation.
TRUST_REPORT
Explicit user report that a call or caller was legitimate or wanted.
May affect reputation.
REPORT_RETRACTION
Withdrawal or correction of an earlier report.
Reduces or reverses the previous report's effect where appropriate.
POLICY_BLOCK
The user's chosen policy caused the client to block the call.
Caller reputation change: zero.
POLICY_ALLOW
The user's policy allowed the call.
Not automatically positive evidence.
OS_BLOCK
The operating system successfully enforced a requested block.
Not reputation evidence.
OS_ALLOW
The operating system allowed the call.
Not reputation evidence.
CALL_OBSERVATION
Privacy-preserving technical evidence such as authentication state, coarse timing, or campaign-related metadata.
Weight depends on provenance and confidence.
NODE_ANALYSIS
Signed node-generated analysis such as:
probable campaign association;
coordinated reporting;
origin-network anomaly;
probable reassignment.
Weight depends on node reputation.
The governing rule is:
A global reputation event is not the same thing as a local policy action.
If a Lockdown user rejects every unknown caller, those rejected callers do not become spam because of it.
Participant Reputation
Not all reports are equally valuable.
Participant reputation may depend on:
historical accuracy;
longevity;
consistency;
willingness to correct mistakes;
independence from coordinated reporting clusters;
absence of abusive behavior;
agreement with later corroborated evidence.
This process should normally remain invisible to Everyday Users.
Cold Start and Trust Bootstrap
New identities begin with limited evidentiary power.
Trust grows through:
slow-start reputation;
long-term participation;
corroborated reports;
bounded sponsorship;
privacy-preserving device or client integrity signals where appropriate;
independence from suspicious clusters.
A new identity does not begin trusted.
A sponsored identity does not inherit the sponsor's reputation.
Eventually, its reputation must become its own.
Sponsorship
A reputable participant may sponsor another participant.
Sponsorship may provide a limited initial trust boost.
That boost:
is bounded;
decays;
can be revoked;
never equals the sponsor's full trust;
can create limited consequences for repeated abusive sponsorship.
Sponsorship is primarily a Power User feature.
Trusted Rings
Power Users and institutions may form federated trust communities.
Examples include:
cybersecurity researchers;
hospitals;
consumer-protection organizations;
geographic communities;
enterprises;
accessibility communities;
telecom researchers.
Everyday Users do not need to configure trusted rings.
The reference client supplies strong defaults.
Ring signals may affect confidence.
They do not create absolute global whitelists or blacklists.
No mandatory central ring weight should be technically unavoidable.
A default client may trust Chickadee Core heavily.
A Power User should be able to reduce, replace, or remove that trust where technically feasible.
Good defaults. No permanent mandatory center.
Federated Nodes
Anyone should be able to operate a Chickadee Meerkat node if they follow the protocol.
Nodes may:
receive privacy-preserving reputation events;
validate signed reports;
identify campaigns;
calculate reputation;
detect coordinated reporting;
detect malicious nodes;
publish signed reputation summaries;
exchange intelligence;
participate in trust relationships.
Nodes themselves are reputation-bearing entities.
Sybil Resistance and Node Abuse
Assume attackers will try to:
create thousands of identities;
operate thousands of nodes;
report themselves trustworthy;
attack competitors;
manipulate campaign analysis;
poison model inputs;
coordinate reporting.
Defenses should include multiple overlapping layers:
persistent identity;
participant reputation;
node reputation;
sponsorship history;
slow-start trust;
correlation analysis;
rate limits;
trust decay;
anomaly detection;
ring moderation;
cross-node corroboration.
No single mechanism is assumed sufficient.
Trust should be cheap to earn honestly and expensive to counterfeit.
AI Architecture
AI helps interpret evidence.
It does not decide what the user must accept.
Possible functions include:
campaign clustering;
anomaly detection;
spoof analysis;
reporting-correlation analysis;
node-abuse detection;
reputation recalculation;
regional-pattern detection;
explanation generation.
The division stays:
AI → evaluates risk
User → decides acceptable risk
Public explainability requires meaningful reason codes.
It does not require publishing the exact thresholds attackers need to defeat the system.
Privacy Boundary
Privacy is defined by what the architecture does, not what the marketing page promises.
Data That Stays Local by Default
contact names;
full contact graph;
raw relationship history;
raw personal call history;
personal notes;
private allowlists;
private blocklists;
civil identity;
named relationship categories;
raw call audio.
Data That May Leave the Device
Only the minimum required for reputation functions.
Possible fields include:
pseudonymous reporter identity;
normalized caller or campaign reference;
event type;
coarse timestamp;
coarse region;
authentication state;
derived behavioral features;
digital signature.
The system should never pretend that simply hashing a telephone number makes it anonymous.
Depending on the function, privacy techniques may include:
aggregation;
keyed identifiers;
private set intersection;
Private Information Retrieval;
differential privacy;
k-anonymity;
secure aggregation;
coarse timing or geography.
Spam Heat counts should not expose isolated reporters.
Exact counts should require a minimum number of independent reports.
Below that threshold, the interface should say:
Insufficient evidence
rather than reveal a tiny reporting pool.
Users should be able to view, retract, and correct their reports and understand what categories of information leave their device.
Two-Speed Intelligence
Chickadee Meerkat separates durable reputation from fast-moving threat intelligence.
Baseline Reputation
Signed updates are distributed at least daily.
They may include:
number reputation;
campaign reputation;
node reputation;
trusted organization data;
regional intelligence.
The client displays when its baseline was last updated.
On-Device Intelligence
Immediate local analysis may use:
contact relationship;
contact recency;
local history;
allow/block rules;
local anomalies.
No network request is required.
Live Intelligence
Where privacy and platform rules permit, the client may query privacy-preserving live intelligence for emerging campaigns.
Live intelligence is supplemental.
It should never become a hidden single point of dependency.
If live lookup fails:
Use signed baseline + local context → reduce confidence if necessary → show that freshness has degraded.
Regional Adaptation
The protocol should work internationally.
Regional implementations may adjust:
numbering systems;
languages;
calling norms;
timezone assumptions;
local scam models;
legal categories;
trusted institutions;
emergency classifications;
model weighting.
The reference client provides good defaults.
Everyday Users do not configure this manually.
Regional implementations remain protocol-compatible.
Open Ecosystem
Chickadee Meerkat permits:
open-source clients;
nonprofit clients;
commercial clients;
managed nodes;
enterprise implementations;
regional implementations;
research implementations.
Commercial products may charge for:
better interfaces;
managed infrastructure;
enterprise controls;
analytics;
advanced models;
support;
integrations.
A commercial client may target ordinary users.
Another may target security professionals.
Both can use the same reputation commons.
No commercial actor gains exclusive ownership over the shared protocol.
No actor may buy favorable reputation.
No actor may pay to remove unfavorable reputation.
Platform Strategy
Android
Android is the reference platform for full policy enforcement.
The five tolerance levels should be directly enforceable wherever Android allows it.
Android is the primary MVP platform.
iOS
iOS may prevent Chickadee Meerkat from fully enforcing a user's policy.
The product therefore distinguishes:
Policy decision
from:
OS enforcement result
Where Apple permits enforcement, use it.
Where Apple does not, provide the strongest available intelligence.
Never hide the difference.
Example:
Your policy: Block
Chickadee assessment: High risk
iOS result: Allowed
Reason: Platform restriction
Everyday Users get plain language.
Power Users may inspect platform diagnostics.
Critical Services
Critical-service status is a signal.
It is not a bypass.
Examples include:
hospitals;
pharmacies;
schools;
utilities;
emergency-adjacent services;
government agencies;
employers;
transportation providers.
Verified critical-service identity may count as positive evidence under Balanced or Permissive settings.
It does not override:
Lockdown;
explicit blocks;
strong contrary evidence;
user-defined policy.
Importance may influence evidence. It does not override user sovereignty.
Callback Protection
A later version of Chickadee Meerkat should evaluate suspicious callbacks as well as incoming calls.
Example:
High-risk callback
This number has strong current risk indicators.
The user still decides whether to proceed.
Appeals and Corrections
Any reputation system will sometimes be wrong.
The network should support correction for:
number reassignment;
incorrect reports;
new ownership;
completed campaigns;
brigading;
model error;
mistaken campaign association.
An organization may verify who it is.
That does not grant positive reputation.
Verification answers:
Who are you?
It does not answer:
Do users want your calls?
Appeal outcomes become evidence.
They are not invisible administrative overrides.
Known Design Tensions
Chickadee Meerkat contains real tradeoffs.
The system should resolve them openly rather than pretend they do not exist.
User Sovereignty vs. Critical Services
Blocking a hospital can matter.
Allowing institutions to bypass Lockdown destroys the product promise.
Rule: The user's explicit policy wins.
Explainability vs. Adversarial Evasion
Users need explanations.
Attackers should not receive an instruction manual.
Rule: Evidence classes and reason codes are visible. Operational anti-abuse thresholds may remain private.
Reputation Decay vs. Campaign Memory
Numbers need to recover after reassignment.
Campaigns should not erase their history by rotating numbers.
Rule: Number reputation decays when ownership changes. Campaign reputation persists independently.
Spam Heat vs. Reporter Privacy
Users want useful counts.
Tiny counts can expose reporters.
Rule: Exact counts require minimum anonymity thresholds.
Live Intelligence vs. Privacy and Resilience
Live queries provide faster protection.
They also create privacy and dependency risks.
Rule: Signed baseline intelligence and local analysis remain functional without a live service.
Simplicity vs. Control
Too many controls overwhelm ordinary users.
Too few controls undermine sovereignty.
Rule: Strong defaults for ordinary users, optional depth for power users.
Open Federation vs. Evidence Quality
Anyone can run a node.
Not every node deserves immediate trust.
Rule: Participation is open. Influence is earned.
Legal and Reputation Safety
Chickadee Meerkat should reduce legal risk through architecture rather than disclaimers alone.
The system should provide:
user-selected enforcement thresholds;
evidence rather than unsupported accusations;
separate community and AI provenance;
reputation decay;
correction and appeal;
data minimization;
no pay-to-clean reputation;
no single authoritative node;
auditable decisions;
no automatic conversion of blocking behavior into accusations;
visible platform limitations.
The interface should favor phrases such as:
reported;
frequently reported;
high risk;
suspected;
unverified;
probable campaign association;
stale classification.
It should not casually describe callers as criminals, scammers, fraudsters, or similar categorical labels unless the available evidence actually supports that statement.
MVP
The first Chickadee Meerkat MVP should prove the core system without pretending to implement the entire future network.
The initial product should include:
one Android reference client;
one trusted reference node;
pseudonymous signed reports;
versioned reputation events;
daily signed reputation updates;
basic campaign detection;
three-indicator caller intelligence;
the five-position tolerance dial;
strict separation between policy and reputation;
false-positive correction;
progressive disclosure.
The single reference node is a deployment shortcut.
It is not the permanent design.
The MVP should prove:
A nontechnical user can install the product, choose a tolerance level, understand the three indicators, report spam, mark a caller trusted, and correct an error.
The five tolerance levels produce meaningfully different call behavior.
Community reports can build reputation without requiring civil identity.
Freshness, Spam Heat, and AI Risk remain separate and understandable.
Reputation intelligence can be refreshed at least daily.
Several telephone numbers can be recognized as belonging to the same probable campaign.
Ordinary users remain in a simple interface while power users can inspect deeper evidence.
A policy block changes caller reputation by exactly zero unless the user explicitly reports the caller.
False-positive corrections propagate through the network.
Reputation information is structured so the network can become genuinely federated later.
Success
The most important metric is not the number of telephone calls blocked.
It is:
How often does prior network knowledge protect someone from a caller or campaign they have never personally encountered?
The most important user-experience question is equally simple:
Can someone who knows nothing about Chickadee Meerkat's architecture install it and use it successfully within minutes?
If the answer to both questions is yes, the network is doing what it was designed to do.
The Core Loop
A caller acts.
↓
Users and nodes observe behavior.
↓
Some users explicitly report or correct calls.
↓
Reputation evidence enters the network.
↓
Policy actions remain separate from reputation.
↓
Nodes and AI identify campaigns, anomalies, number reassignment, and attempted manipulation.
↓
Reputation changes.
↓
Updated intelligence propagates.
↓
The phone combines network reputation with private local relationship context.
↓
The user's tolerance setting determines the desired action.
↓
The operating system enforces that action where permitted.
↓
The user receives a simple explanation.
↓
Power Users can inspect the deeper evidence.
↓
Corrections, reports, and valid observations become new evidence.
That loop is Chickadee Meerkat.
No comments:
Post a Comment