System Requirements Document for bitshield-2

1. Introduction

BITSHIELD — Bitcoin Scam Risk Detector is a single-file, fully offline web application that helps a person who has received a suspicious Bitcoin message understand why that message may be risky. The user pastes a message into an evidence workspace; a local, transparent rule engine then produces a Risk Score (0–100), a Risk Level (LOW / MEDIUM / HIGH / CRITICAL), the warning signs that matched, the exact suspicious phrases highlighted inside the original message, beginner-friendly reasons, a scam-type classification, a scam-stage tracker, a mathematical reality check on any return claims, a dynamic "what to do now" checklist, and the list of rules that were checked but did not match.

The product is deliberately not a simple scam / not-scam verdict. Its flow is RISK SCORE → WARNING SIGNS → WHY RISKY → WHAT TO CHECK, and it presents its reasoning as a printed forensic ledger rather than a single answer. The audience is everyday Bitcoin users who are anxious and unfamiliar with crypto jargon, plus students presenting this as a college cybersecurity project demo. The emotional register is calm authority, forensic honesty, and quiet reassurance — a lab report, not an alarm.

The application uses sample/test data only. It never handles real Bitcoin, keys, or payments, and it makes no network requests of any kind.

2. System Overview

BITSHIELD is delivered as one self-contained HTML file: HTML markup, CSS inside a <style> element, and vanilla JavaScript inside a <script> element. There are no frameworks, libraries, backends, APIs, databases, wallets, blockchain calls, or external requests. The app works fully offline.

Actors. Two accepted human personas use the product: the Suspicious Message Recipient, who pastes a message and reads the evidence trail, and the Cybersecurity Student Demonstrator, who runs the built-in samples and the self-test to prove the analyzer's logic to an audience. There are no system, provider, or external-service actors that own any user-facing behavior; all analysis, scoring, highlighting, practice feedback, and self-test execution happen locally in the browser.

Accepted behavior. The app loads the "Guaranteed Profit" sample and analyzes it on entry. The user can type or paste a message (max 5000 characters, live counter), load any of five supplied samples, clear the field, and run the check. The rule engine holds 18–20 rules, each with an id, label, weight, regex, explanation, tip, family, and stage. Scoring sums matched weights, applies a +12 bonus when urgency and payment rules both match, and converts the sum with score = round(100 × (1 − e^(−sum/45))), capped at 100. Results are rendered as a rotated stamp verdict, a numeric score, a text progress bar, a full arithmetic breakdown, evidence-tape highlights, warning-sign findings, a scam-type card, a five-stage tracker, a reality check, a dynamic checklist, and a checked-and-clear list. Practice mode holds exactly six scenarios; the self-test really runs the analyzer against all five samples and reports PASS/FAIL lines.

Narrow exclusions. BITSHIELD does not perform real transactions, blockchain operations, or external lookups. It does not handle real Bitcoin, payment details, keys, or addresses. It does not present a legal determination, and it does not claim that a low score proves a message is legitimate.

2a. Product Interpretation and Delivery Boundary

BITSHIELD is a local, anonymous, offline tool. There is no account, no sign-in, no server, and no data transmission — the header states this explicitly with the status labels OFFLINE DEMO, NO REAL CRYPTO, and NO DATA SENT. Every destination in the app is reachable without identity, because no accepted journey requires durable actor-specific state to be privately owned or resumed across sessions. Optional localStorage use is permitted only inside try/catch and never gates any capability.

The delivery boundary is a single HTML file that runs from the local filesystem or any static host with no build step and no runtime dependencies. All current behavior — analysis, scoring, highlighting, classification, stage tracking, reality check, checklist, practice, and self-test — is in scope now. The only outbound interaction in the entire product is the India Cyber Crime Portal link in the "What to do now" checklist, which opens in a new tab with rel="noopener noreferrer"; it is a user-initiated navigation, not a background request, and the app remains fully functional offline without it.

2b. Source Content Inventory

The reference directive for https://cybercrime.gov.in/ declares uses: ["domain_context"] with supplemental authority and instructs that it be included as the India Cyber Crime Portal link in the "What to do now" checklist, opening in a new tab with rel="noopener noreferrer". Because this directive does not declare content_source, no content inventory is produced. The link and the Helpline 1930 reference are carried as domain context in the checklist requirement and in the Results page coverage.

2c. Page Content and Component Coverage

Landing

• Information and state: The public entry surface. Presents the BITSHIELD wordmark with the simple CSS shield mark (no emoji logo), the title "Bitcoin Scam Risk Detector", the three status labels OFFLINE DEMO, NO REAL CRYPTO, NO DATA SENT, and the line "Analyze suspicious Bitcoin messages using transparent warning patterns and understand why a message may be risky." Explains who the tool is for (everyday Bitcoin users and students), that analysis is local and offline, and that the app uses sample/test data only and never handles real Bitcoin or money.
• Primary actions: Enter the analyzer workspace.
• Supporting actions: Read the scope and honesty statements; reach the practice and self-test destinations.
• Domain entities: Status labels, scope statement, footer disclaimer.
• Component responsibilities: Header block (wordmark, shield mark, status chips, subtext); scope panel stating offline/sample-only boundaries; entry control into the analyzer; footer disclaimer text.
• States: Loading — none required (static content). Empty — not applicable. Success — static render. Error — none. Recovery — not applicable.

Analyzer

• Information and state: The evidence-entry workspace. Section heading "Submit the Evidence" with the label "Suspicious message or offer" bound to a large textarea, a live character counter reading "0 / 5000", and the five sample buttons: Fake Giveaway, Guaranteed Profit, Fake Support, Withdrawal Fee, Normal Question. On page load the Guaranteed Profit sample is loaded into the textarea, the counter updates, and analysis runs automatically.
• Primary actions: CHECK MESSAGE (run the analyzer on the current textarea contents); CLEAR (empty the textarea and reset the counter).
• Supporting actions: Click any of the five sample buttons to fill the textarea, update the counter, and auto-analyze.
• Domain entities: Message text (max 5000 characters), character counter, sample definitions, validation messages.
• Component responsibilities: Labeled textarea with maxlength; live counter; sample button row; check and clear controls; friendly validation messaging region.
• States: Loading — none (analysis is synchronous and local). Empty — empty or whitespace-only input produces a friendly prompt to paste a message, never a raw error. Success — analysis runs and the Results content updates. Error — emoji, Unicode, non-English, long, and pasted text are all handled with friendly messages; analysis is wrapped in try/catch and raw errors are never shown. Recovery — the user can clear, edit, or load a sample and re-run at any time.

Results

• Information and state: The revisitable analysis destination. Presents, in hierarchy order: the rotated stamp-style risk level; the numeric score in the form "86 / 100"; a text progress bar; the "Why this score?" arithmetic ledger; the highlighted original message with evidence-tape labels; "Warning Signs Detected"; the scam-type card; the stage tracker; the reality check; the "What to do now" checklist; and "Checked and Clear". All dynamic updates are wrapped in aria-live.
• Primary actions: Click a highlight to scroll to and focus its finding; read the score breakdown; follow the checklist.
• Supporting actions: Open the India Cyber Crime Portal link in a new tab; read the checked-and-clear list; return to the analyzer to check another message.
• Domain entities: Risk score, risk level, matched rules with weights, bonus flag, formula, matched phrases, findings (severity, rule name, matched evidence, why risky, what to check), strongest family, active stages, detected rate claim and compounded yearly return, checklist items, unmatched rules.
• Component responsibilities: Stamp verdict block; score readout; 24-block text progress bar; "Why this score?" ledger with aligned label/value rows and hairline rules; evidence sheet rendering the original message with taped highlight labels; findings list; scam-type card with "How it works" and the educational-classification note; five-marker stage tracker (HOOK → TRUST → PRESSURE → PAYMENT → EXIT); reality-check card; dynamic checklist; checked-and-clear list.
• States: Loading — none. Empty — before any analysis, the result region shows its initial state; on load it is already populated by the Guaranteed Profit analysis. Success — stamp, score, bar, ledger, highlights, findings, classification, stages, reality check, checklist, and clear list all render. Error — any analysis exception is caught and surfaced as a friendly message; no raw error text is displayed. Recovery — the user edits or reloads a sample and re-runs; the result sheet re-renders with the single entrance fade/slide.

Practice

• Information and state: Exactly six scam-recognition scenarios, each with a short description and a SCAM and a SAFE button. Scenarios cover: send BTC to get more back; a simple Bitcoin price question; a seed phrase request; a recovery fee; the statement "Never share your seed phrase"; and independent verification.
• Primary actions: Choose SCAM or SAFE for a scenario.
• Supporting actions: Read the correct/incorrect feedback and its plain-language explanation; continue to the next scenario.
• Domain entities: Scenario description, expected answer, user answer, feedback text, explanation.
• Component responsibilities: Scenario list; per-scenario answer buttons; feedback region.
• States: Loading — none. Empty — all six scenarios are always present. Success — correct answer shows confirmation plus explanation. Error — incorrect answer shows a correction plus explanation, framed as learning rather than failure. Recovery — the user can answer the remaining scenarios and revisit any scenario.

Self-Test

• Information and state: A RUN SELF-TEST button and a results region. Running it executes the real analyzer against all five samples, compares each result to its expected level, and prints one line per sample in the form "Fake Giveaway ..... PASS", followed by "5/5 SELF-TESTS PASSED" (or "X/5").
• Primary actions: Run the self-test.
• Supporting actions: Read per-sample PASS/FAIL lines and the aggregate count.
• Domain entities: Sample name, expected level, actual level, pass/fail, aggregate count.
• Component responsibilities: Run control; monospace result lines; aggregate summary.
• States: Loading — none (synchronous local execution). Empty — before running, the region shows the run control only. Success — all five lines PASS and the aggregate reads "5/5 SELF-TESTS PASSED". Error — any failing sample is shown as FAIL with its actual level, and the aggregate reads "X/5". Recovery — the button can be run again at any time.

3. Functional Requirements

FR-01 — Single-file offline delivery (explicit) As a Suspicious Message Recipient, I should be able to open BITSHIELD as one self-contained HTML file with all CSS in a <style> element and all JavaScript in a <script> element, so that the tool works fully offline with no frameworks, libraries, backend, API, database, wallet, blockchain, or external requests. Lifecycle: Trigger — the file is opened. Observable result — the app renders and functions with no network activity. Failure/recovery — if any optional feature fails, the core analyzer still works. Continuation — the user proceeds to submit evidence.

FR-02 — Font stacks (explicit) As a Suspicious Message Recipient, I should see headings rendered with "Bricolage Grotesque", Arial, system-ui, body text with "IBM Plex Sans", system-ui, and evidence text with "IBM Plex Mono", ui-monospace, monospace, so that the interface reads as a forensic report even when the named fonts are unavailable. Lifecycle: Trigger — any render. Observable result — the correct fallback chain applies per text role. Failure/recovery — missing fonts fall back gracefully. Continuation — reading continues.

FR-03 — Header identity and status (explicit) As a Suspicious Message Recipient, I should see the header "BITSHIELD / Bitcoin Scam Risk Detector" with the status labels OFFLINE DEMO, NO REAL CRYPTO, NO DATA SENT and the text "Analyze suspicious Bitcoin messages using transparent warning patterns and understand why a message may be risky.", so that I immediately understand the tool's scope and honesty boundaries. Lifecycle: Trigger — page load. Observable result — header renders with wordmark, status labels, and subtext. Failure/recovery — static content, no failure path. Continuation — the user reads the scope and proceeds.

FR-04 — Evidence submission input (explicit) As a Suspicious Message Recipient, I should see a "Submit the Evidence" section with the label "Suspicious message or offer", a large textarea limited to 5000 characters, and a live counter reading "0 / 5000", so that I can paste the message I want analyzed and see how much room remains. Lifecycle: Trigger — typing or pasting. Observable result — the counter updates live and input is capped at 5000 characters. Failure/recovery — over-length input is prevented or trimmed with a friendly message. Continuation — the user runs the check.

FR-05 — Check and clear controls (explicit) As a Suspicious Message Recipient, I should have CHECK MESSAGE and CLEAR buttons, so that I can run the analysis or reset the field. Lifecycle: Trigger — button activation. Observable result — CHECK MESSAGE runs the analyzer; CLEAR empties the textarea and resets the counter to "0 / 5000". Failure/recovery — clearing is always available. Continuation — the user pastes a new message or re-runs.

FR-06 — Friendly input handling (explicit) As a Suspicious Message Recipient, I should receive friendly messages for empty, whitespace-only, emoji, Unicode, non-English, long, and pasted text, with analysis wrapped in try/catch and no raw errors ever shown, so that I am never confronted with a technical failure. Lifecycle: Trigger — any of these input conditions. Observable result — a plain-language message explains the situation. Failure/recovery — exceptions are caught and replaced with friendly text. Continuation — the user edits the input and retries.

FR-07 — Five sample buttons (explicit) As a Suspicious Message Recipient, I should have five sample buttons — Fake Giveaway, Guaranteed Profit, Fake Support, Withdrawal Fee, and Normal Question — where clicking fills the textarea, updates the counter, and auto-analyzes, so that I can see the tool work on known examples. Lifecycle: Trigger — sample button click. Observable result — the textarea is populated, the counter updates, and analysis runs immediately. Failure/recovery — samples are static and always available. Continuation — the user reads the results or loads another sample.

FR-08 — Verbatim sample texts (explicit) As a Suspicious Message Recipient, I should see these exact sample texts when I load them:

• Fake Giveaway: "Congratulations! You have been selected for an exclusive Bitcoin giveaway. Send 0.01 BTC to the address below and we will send 0.1 BTC back. Act now, this offer expires in 10 minutes!"
• Guaranteed Profit: "Our private Bitcoin investment program guarantees 8% daily profit with zero risk. Deposit BTC today and your returns are guaranteed. Pay a small upfront activation fee before withdrawal."
• Fake Support: "URGENT SECURITY ALERT: Your Bitcoin exchange account will be suspended today. I am from exchange support. Verify your wallet immediately by sending your seed phrase or private key to our support agent."
• Withdrawal Fee: "Your Bitcoin withdrawal is ready, but a refundable 0.02 BTC compliance fee must be paid first. Send the fee to unlock your funds. If you do not pay today, your account may face legal action."
• Normal Question: "Hi, I am learning about Bitcoin. What is the difference between a Bitcoin wallet address and a private key? I will never share my seed phrase." Lifecycle: Trigger — sample selection. Observable result — the exact text appears in the textarea. Failure/recovery — none needed. Continuation — analysis runs.

FR-09 — Auto-load Guaranteed Profit on entry (explicit) As a Suspicious Message Recipient, I should have the Guaranteed Profit sample auto-loaded and analyzed when the page loads, so that the tool demonstrates its full output immediately. Lifecycle: Trigger — page load. Observable result — the textarea contains the Guaranteed Profit text and the Results content is populated. Failure/recovery — if analysis fails, a friendly message appears and the user can re-run. Continuation — the user reads the results or loads another sample.

FR-10 — Rule engine structure (explicit) As a Suspicious Message Recipient, I should be analyzed by a JavaScript array of 18–20 rules, each carrying an id, label, weight, regex, explanation, tip, family, and stage, so that every warning is traceable to a named, weighted pattern. Lifecycle: Trigger — analysis run. Observable result — matched rules carry all eight fields into the results. Failure/recovery — a rule that fails to evaluate is skipped without breaking the run. Continuation — scoring proceeds.

FR-11 — Rule coverage (explicit) As a Suspicious Message Recipient, I should have the rule set cover guaranteed profit, unrealistic returns, Bitcoin giveaway, send BTC to get more back, urgency, seed phrase request, private key request, fake exchange support, fake security alert, gift card payment, crypto ATM payment, wallet address, short links, look-alike domains, secrecy, upfront fees, recovery scam, remote-access software, legal threats, password/OTP request, and unexpected crypto payment demand, so that the common Bitcoin scam patterns are all represented. Lifecycle: Trigger — analysis run against a message containing any of these patterns. Observable result — the corresponding rule matches and appears in the findings. Failure/recovery — unmatched patterns appear in Checked and Clear. Continuation — the user reads the findings.

FR-12 — Negation handling (explicit) As a Suspicious Message Recipient, I should have "Never share your seed phrase" and "Do not send Bitcoin" NOT trigger their rules, so that safe advice is not misread as a scam signal. Lifecycle: Trigger — analysis of a message containing negated advice. Observable result — the seed-phrase and send-Bitcoin rules do not match, and the Normal Question sample scores LOW. Failure/recovery — if a negation is missed, the self-test surfaces the discrepancy. Continuation — the user trusts the low-risk reading.

FR-13 — Safe regex constraint (explicit) As a Suspicious Message Recipient, I should have all rule regexes use safe patterns only — no nested quantifiers, with bounded wildcards such as [\s\S]{0,60} — so that analysis never hangs or crashes the page. Lifecycle: Trigger — analysis run. Observable result — evaluation completes promptly on any input. Failure/recovery — a pathological input is still bounded by the wildcard limits. Continuation — results render.

FR-14 — Risk scoring formula (explicit) As a Suspicious Message Recipient, I should have my message scored by summing matched rule weights, applying a +12 bonus to the sum when urgency and payment rules both match, and converting with score = round(100 × (1 − e^(−sum/45))), capped at 100, so that the score reflects both the number and the severity of matched patterns. Lifecycle: Trigger — analysis run. Observable result — a numeric score from 0 to 100. Failure/recovery — the cap prevents overflow. Continuation — the level is derived from the score.

FR-15 — Risk levels (explicit) As a Suspicious Message Recipient, I should see my message classified as LOW (0–24), MEDIUM (25–47), HIGH (48–71), or CRITICAL (72–100), so that I get a graded reading rather than a binary verdict. Lifecycle: Trigger — score computed. Observable result — the level label renders in the stamp. Failure/recovery — boundary values map to exactly one level. Continuation — the user reads the findings.

FR-16 — Target level accuracy (explicit) As a Cybersecurity Student Demonstrator, I should see Fake Giveaway, Guaranteed Profit, and Fake Support score CRITICAL, Withdrawal Fee score HIGH, and Normal Question score LOW, with weights tuned so these pass, so that the demo proves the engine works as specified. Lifecycle: Trigger — self-test or manual sample load. Observable result — each sample lands in its expected level. Failure/recovery — a mismatch is reported as FAIL. Continuation — the demonstrator explains the tuning.

FR-17 — Score presentation (explicit) As a Suspicious Message Recipient, I should see a prominent stamp-style risk level, a numeric score in the form "86 / 100", and a text progress bar, so that the verdict is the loudest element on the page. Lifecycle: Trigger — analysis completes. Observable result — stamp, score, and bar render. Failure/recovery — the bar reflects the numeric score exactly. Continuation — the user reads the breakdown.

FR-18 — "Why this score?" breakdown (explicit) As a Suspicious Message Recipient, I should see a "Why this score?" section listing each matched pattern with its weight, the bonus if applied, the formula, and the final score, so that the arithmetic is fully transparent. Lifecycle: Trigger — analysis completes. Observable result — an aligned ledger of rule names and weights, the bonus line, the formula line, and the total. Failure/recovery — with no matches, the ledger shows an empty sum and the formula still displays. Continuation — the user reads the findings.

FR-19 — Aria-live updates (explicit) As a Suspicious Message Recipient using a screen reader, I should have score and result updates announced through aria-live, so that I learn about changes without hunting the page. Lifecycle: Trigger — any result update. Observable result — the live region announces the new score and level. Failure/recovery — repeated updates remain concise. Continuation — the user navigates to details.

FR-20 — Evidence highlighting (explicit) As a Suspicious Message Recipient, I should see the original message rendered with matched phrases in evidence-tape styling, so that I can see exactly which words triggered each warning. Lifecycle: Trigger — analysis completes. Observable result — matched phrases are wrapped in taped labels within the message text. Failure/recovery — unmatched text renders plainly. Continuation — the user inspects the highlights.

FR-21 — Safe DOM rendering (explicit) As a Suspicious Message Recipient, I should have my message rendered only with textContent, createElement, and appendChild, never with innerHTML, and with no eval or Function, so that pasted content can never execute. Lifecycle: Trigger — any render of user text. Observable result — the text appears literally, including any markup characters. Failure/recovery — no injection path exists. Continuation — the user reads the evidence safely.

FR-22 — Clickable highlights (explicit) As a Suspicious Message Recipient, I should be able to click a highlight to scroll to and focus its corresponding finding, so that I can connect evidence to explanation. Lifecycle: Trigger — highlight click or keyboard activation. Observable result — the matching finding receives focus and is brought into view. Failure/recovery — if the finding is already visible, focus still moves. Continuation — the user reads the finding.

FR-23 — Warning Signs Detected (explicit) As a Suspicious Message Recipient, I should see a "Warning Signs Detected" section where each entry shows severity, rule name, matched evidence, why it is risky, and what to check, in plain beginner language, so that I understand each warning without jargon. Lifecycle: Trigger — analysis completes with matches. Observable result — one entry per matched rule with all five fields. Failure/recovery — with no matches, the section states that no warning signs were detected. Continuation — the user reads the checklist.

FR-24 — Scam type card (explicit) As a Suspicious Message Recipient, I should see a scam-type card showing the strongest matched family from Investment, Giveaway, Impersonation, Credential Theft, Phishing, Pressure, Advance Fee, Recovery, Device Takeover, and Payment, with the family name and a "How it works" explanation, plus a note that this is an educational classification and not a legal determination. Lifecycle: Trigger — analysis completes. Observable result — the strongest family and its explanation render with the disclaimer. Failure/recovery — with no matches, the card states that no family was identified. Continuation — the user reads the stage tracker.

FR-25 — Stage tracker (explicit) As a Suspicious Message Recipient, I should see a stage tracker reading HOOK → TRUST → PRESSURE → PAYMENT → EXIT with the stages active according to matched rules, horizontal on desktop and stacked on mobile, so that I can see how far the message has progressed through a typical scam sequence. Lifecycle: Trigger — analysis completes. Observable result — active stages are marked and inactive stages are shown as inactive. Failure/recovery — with no matches, no stage is active. Continuation — the user reads the reality check.

FR-26 — Math reality check (explicit) As a Suspicious Message Recipient, I should have any "X% daily/weekly/monthly" claim detected and its compounded yearly return computed and displayed (for example, (1.08^365 − 1) × 100), together with the note "This is a mathematical reality check, not proof that the sender's claim is true. Extremely large repeated returns are a reason to stop and independently verify the offer.", so that I can see how implausible the claim is. Lifecycle: Trigger — a rate claim is detected. Observable result — the detected rate and the compounded yearly figure render with the note. Failure/recovery — with no rate claim, the card states that no return claim was detected. Continuation — the user reads the checklist.

FR-27 — Dynamic "What to do now" checklist (explicit) As a Suspicious Message Recipient, I should see a dynamic checklist: at high risk, do not send Bitcoin, do not pay upfront fees, verify independently, never share seed phrase/private key/passwords/OTP, do not install remote-access software, do not click suspicious links, and ignore deadlines; at low risk, keep verifying, do not share credentials, and verify payment requests independently. The checklist should include the India Cyber Crime Portal at https://cybercrime.gov.in/ opening in a new tab with rel="noopener noreferrer", and Helpline 1930. Lifecycle: Trigger — analysis completes. Observable result — the checklist items appropriate to the level render, with the portal link and helpline. Failure/recovery — the link is user-initiated and the app remains functional offline without it. Continuation — the user acts on the guidance.

FR-28 — Checked and Clear (explicit) As a Suspicious Message Recipient, I should see a "Checked and Clear" list of the rules that did not match, each with a check mark, plus the note "No matched rule is not proof that a message is legitimate.", so that I understand what was tested and that a clean result is not a guarantee. Lifecycle: Trigger — analysis completes. Observable result — unmatched rules are listed with check marks and the note. Failure/recovery — if all rules matched, the list is empty and the note still displays. Continuation — the user reads the practice mode.

FR-29 — Practice mode (explicit) As a Suspicious Message Recipient, I should have exactly six practice scenarios, each with SCAM and SAFE buttons followed by correct/incorrect feedback and an explanation, covering send BTC to get more back, a simple Bitcoin price question, a seed phrase request, a recovery fee, "Never share your seed phrase", and independent verification, so that I can rehearse the judgment the tool teaches. Lifecycle: Trigger — the user answers a scenario. Observable result — immediate correct/incorrect feedback with an explanation. Failure/recovery — an incorrect answer is corrected with an explanation rather than a dead end. Continuation — the user answers the remaining scenarios.

FR-30 — Self-test (explicit) As a Cybersecurity Student Demonstrator, I should have a RUN SELF-TEST button that really runs the analyzer on all five samples, compares each to its expected level, and shows lines such as "Fake Giveaway ..... PASS" followed by "5/5 SELF-TESTS PASSED" (or "X/5"), so that I can prove the engine works without any backend. Lifecycle: Trigger — button activation. Observable result — five PASS/FAIL lines and an aggregate count. Failure/recovery — a failing sample shows FAIL with its actual level. Continuation — the demonstrator explains the results.

FR-31 — Accessibility (explicit) As a Suspicious Message Recipient, I should have proper labels, full keyboard navigation, visible focus, aria-live regions, WCAG AA contrast, meaning never conveyed by color alone, and touch-friendly buttons, so that the tool is usable regardless of input method or vision. Lifecycle: Trigger — any interaction. Observable result — every control is labeled, reachable, and visibly focused. Failure/recovery — no control depends on color alone. Continuation — the user completes the task.

FR-32 — Responsive layout (explicit) As a Suspicious Message Recipient, I should have the app work at 320, 360, and 390 px, on tablet, and on desktop with no horizontal scroll; mobile is a single column with full-width buttons, and desktop is two columns with the input, highlighted message, and findings on the left and the scam type, reality check, what to do, checked and clear, practice, and self-test on the right. Lifecycle: Trigger — viewport change. Observable result — the layout reflows without horizontal scroll. Failure/recovery — long words and evidence text wrap rather than overflow. Continuation — the user reads and acts.

FR-33 — Light and dark theme (explicit) As a Suspicious Message Recipient, I should have light and dark themes driven by CSS variables following prefers-color-scheme, where dark mode uses dark blue-grey paper, light ink, muted borders, and the deep red stamp, and is not cyberpunk, so that the tool is comfortable in either environment. Lifecycle: Trigger — system theme change. Observable result — the theme switches via variables. Failure/recovery — the light theme remains the default fallback. Continuation — reading continues.

FR-34 — Single entrance animation (explicit) As a Suspicious Message Recipient, I should see only one subtle entrance fade/slide on the analysis result, a static slight stamp rotation, and all motion disabled under prefers-reduced-motion, so that the interface feels calm and never theatrical. Lifecycle: Trigger — a new analysis runs. Observable result — the result sheet fades and slides in once; the stamp stays statically rotated. Failure/recovery — under reduced motion the final state appears immediately. Continuation — the user reads the results.

FR-35 — Optional localStorage (explicit) As a Suspicious Message Recipient, I should have any localStorage use wrapped in try/catch, so that storage being unavailable never breaks the app. Lifecycle: Trigger — any optional persistence attempt. Observable result — the app works identically whether or not storage succeeds. Failure/recovery — a storage exception is swallowed. Continuation — the session proceeds normally.

FR-36 — Visual hierarchy (explicit) As a Suspicious Message Recipient, I should see the risk level and score as the loudest elements, followed by warning signs, highlighted evidence, why risky, and what to do, with secondary cards quieter, so that my attention goes to the verdict and its reasoning first. Lifecycle: Trigger — results render. Observable result — the stamp and score dominate; secondary cards recede. Failure/recovery — hierarchy holds at every viewport. Continuation — the user reads downward.

FR-37 — Footer disclaimer (explicit) As a Suspicious Message Recipient, I should see the footer text "BitShield provides pattern-based educational guidance, not proof that a message is a scam or legitimate. Always verify important claims independently. This demo uses sample/test data only and never handles real Bitcoin or money.", so that the tool's limits are always stated. Lifecycle: Trigger — page render. Observable result — the disclaimer appears in the footer. Failure/recovery — static content. Continuation — the user closes or continues.

FR-38 — Final quality checks (explicit) As a Cybersecurity Student Demonstrator, I should be able to confirm no console errors, all five sample levels correct, negation working, the bonus working, the formula shown, highlights safe and clickable, six practice questions, the self-test truly running, and the app working offline, so that the demo is verifiably complete. Lifecycle: Trigger — demonstration run. Observable result — every check passes. Failure/recovery — any failure is visible in the self-test or console. Continuation — the demonstration concludes.

FR-39 — Local-only execution (required_inference) As a Suspicious Message Recipient, I should have all analysis, scoring, highlighting, practice feedback, and self-test execution occur locally in the browser with no backend or external service, so that my pasted message never leaves my device. Lifecycle: Trigger — any analysis or test run. Observable result — results appear with no network activity. Failure/recovery — no network dependency exists to fail. Continuation — the user reads the results.

FR-40 — Anonymous access to all destinations (required_inference) As a Suspicious Message Recipient, I should reach the Landing, Analyzer, Results, Practice, and Self-Test destinations without creating an account or signing in, so that I can use the tool immediately and anonymously. Lifecycle: Trigger — navigation. Observable result — every destination renders without an identity gate. Failure/recovery — no identity state exists to fail. Continuation — the user completes their task.

4. User Personas

Suspicious Message Recipient

Product context. This person has received a Bitcoin-related message — a giveaway announcement, an investment pitch, a support alert, a withdrawal notice — and is uneasy about it. They are not crypto experts. They may not know what a seed phrase is, or why a "refundable compliance fee" is a warning sign. They are often on a phone, reading in a hurry, and they want a straight answer about why the message is risky rather than a bare verdict.

Primary goal. To understand, in plain language, which parts of the message are dangerous, how dangerous the message is overall, and what to do next.

Distinct accepted responsibilities. This persona pastes or types a message into the evidence field, watches the character counter, optionally loads one of the five samples, and runs the check. They read the stamp verdict and score, then the "Why this score?" ledger, then the highlighted evidence, then the warning signs, then the scam type and stage tracker, then the reality check, then the checklist. They click a highlight to jump to its finding. They read the checked-and-clear list and absorb the caveat that a clean result is not proof of legitimacy. They may then work through the six practice scenarios to rehearse the judgment.

Relevant inputs and decisions. The message text (up to 5000 characters, including emoji, Unicode, and non-English text). The decision to check, clear, or load a sample. The decision of which highlight to follow. The decision of whether to act on the checklist.

Interactions with other accepted participants. This persona does not interact with the Cybersecurity Student Demonstrator inside the product; the two use the same destinations independently. The only outbound interaction is the user-initiated India Cyber Crime Portal link, which opens in a new tab.

Observable success. The user can state which phrases triggered warnings, what the score and level are, why the score is what it is, what scam type and stage the message resembles, whether any return claim is mathematically plausible, and what concrete steps to take next — all without any data leaving the device.

Cybersecurity Student Demonstrator

Product context. This person is presenting BITSHIELD as a college cybersecurity project. They need the app to look and behave like a finished tool, not a mockup, and they need its reasoning to be inspectable in front of an audience. They are comfortable with the rule engine's structure and want to show it off.

Primary goal. To demonstrate, live and offline, that the analyzer produces correct, explainable results on known inputs.

Distinct accepted responsibilities. This persona loads the app and lets the Guaranteed Profit sample auto-analyze on entry. They walk the audience through the stamp verdict, the score, the arithmetic ledger, the evidence highlights, and the findings. They load each of the five samples in turn and show the expected levels. They run the self-test and read the PASS lines and the aggregate count. They explain the negation handling using the Normal Question sample. They explain the urgency-plus-payment bonus using a sample where both fire. They may also use the practice mode to show the teaching layer.

Relevant inputs and decisions. The choice of which sample to load and in what order. The decision to run the self-test before or after the manual walkthrough. The decision to explain the formula, the bonus, or the negation rule in more or less depth.

Interactions with other accepted participants. This persona does not interact with the Suspicious Message Recipient inside the product. Their demonstration depends on the same local engine that the recipient uses.

Observable success. All five samples land in their expected levels, the self-test reports "5/5 SELF-TESTS PASSED", the formula and bonus are visible on screen, the highlights are clickable, and the whole demonstration runs with no console errors and no network access.

5. Core User Flows

Flow 1 — Recipient checks a suspicious message they received

1. The recipient opens BITSHIELD. The Landing surface renders the wordmark, the CSS shield mark, the status labels OFFLINE DEMO, NO REAL CRYPTO, NO DATA SENT, and the scope statement.
2. The recipient enters the Analyzer. The Guaranteed Profit sample is already loaded in the textarea, the counter reads its length out of 5000, and the Results content is already populated from the automatic analysis.
3. The recipient selects the textarea, clears it with CLEAR, and pastes the message they actually received. The counter updates live and the input is capped at 5000 characters.
4. The recipient activates CHECK MESSAGE. The analyzer runs locally inside try/catch.
5. The Results surface updates inside aria-live. The rotated stamp shows the risk level, the score reads in the form "86 / 100", and the text progress bar fills to match.
6. The recipient reads the "Why this score?" ledger: each matched rule appears as an aligned label/value row with its weight, followed by the bonus line if urgency and payment both matched, then the formula score = round(100 × (1 − e^(−sum/45))), then the final score.
7. The recipient reads the highlighted message. Each matched phrase is wrapped in an evidence-tape label carrying the rule's short name.
8. The recipient clicks a highlight. The page scrolls to and focuses the corresponding finding.
9. The recipient reads "Warning Signs Detected": for each entry, the severity, the rule name, the matched evidence, why it is risky, and what to check.
10. The recipient reads the scam-type card, which names the strongest matched family and explains "How it works", with the note that this is an educational classification and not a legal determination.
11. The recipient reads the stage tracker and sees which of HOOK, TRUST, PRESSURE, PAYMENT, and EXIT are active.
12. The recipient reads the reality check. If the message claimed a recurring percentage return, the detected rate and the compounded yearly figure are shown with the note that this is a mathematical reality check and not proof the claim is true.
13. The recipient reads the "What to do now" checklist, which reflects the risk level, and follows the India Cyber Crime Portal link (opening in a new tab with rel="noopener noreferrer") or notes Helpline 1930.
14. The recipient reads "Checked and Clear" and the note that no matched rule is not proof that a message is legitimate.
15. Failure and recovery: if the recipient pastes an empty or whitespace-only field, or text that is emoji-only, non-English, or over-long, a friendly message explains the situation and no raw error appears. The recipient edits the input and re-runs.
16. Continuation: the recipient clears the field and checks another message, or moves to Practice.

Flow 2 — Recipient rehearses judgment in Practice

1. The recipient opens the Practice surface.
2. Exactly six scenarios are listed, each with a short description and SCAM and SAFE buttons.
3. The recipient reads the first scenario — a message offering to send more BTC back — and selects SCAM.
4. Feedback appears immediately: correct, with a plain-language explanation of why the offer is a scam pattern.
5. The recipient continues through the remaining scenarios: a simple Bitcoin price question, a seed phrase request, a recovery fee, the statement "Never share your seed phrase", and an independent-verification step.
6. Failure and recovery: on a scenario where the recipient selects the wrong answer, the feedback states that the answer is incorrect and explains the correct reading, framed as learning rather than failure.
7. Continuation: the recipient finishes all six scenarios and returns to the Analyzer to check a real message with better judgment.

Flow 3 — Student demonstrates the analyzer

1. The student opens BITSHIELD in front of an audience. The Landing surface states the offline, sample-only scope.
2. The student enters the Analyzer. The Guaranteed Profit sample has auto-loaded and auto-analyzed, so the Results surface is already populated.
3. The student points out the stamp verdict, the score, and the progress bar, then walks through the "Why this score?" ledger, naming the matched rules and their weights and reading the formula aloud.
4. The student clicks a highlight to show that it scrolls to and focuses its finding, then reads the severity, rule name, matched evidence, why risky, and what to check for that entry.
5. The student loads the Fake Giveaway sample. The textarea fills, the counter updates, and analysis runs automatically; the level reads CRITICAL.
6. The student loads the Fake Support sample and shows the CRITICAL level, then the Withdrawal Fee sample and shows the HIGH level.
7. The student loads the Normal Question sample and shows the LOW level, explaining that "Never share your seed phrase" is negated and does not trigger the seed-phrase rule.
8. The student opens the Self-Test surface and activates RUN SELF-TEST. The analyzer really runs against all five samples and prints lines such as "Fake Giveaway ..... PASS", ending with "5/5 SELF-TESTS PASSED".
9. Failure and recovery: if any sample lands in the wrong level, its line reads FAIL with the actual level and the aggregate reads "X/5"; the student can re-run after inspecting the rule weights.
10. Continuation: the student returns to the Analyzer or Practice to answer audience questions, with no console errors and no network activity throughout.

Flow 4 — Recipient reads a clean result honestly

1. The recipient pastes a message that matches no rules and activates CHECK MESSAGE.
2. The stamp shows LOW, the score is low, and the progress bar is nearly empty.
3. The "Why this score?" ledger shows an empty sum and still displays the formula.
4. "Warning Signs Detected" states that no warning signs were detected.
5. The scam-type card states that no family was identified, and no stage is active in the tracker.
6. The reality check states that no return claim was detected.
7. The "What to do now" checklist shows the low-risk guidance: keep verifying, do not share credentials, and verify payment requests independently.
8. "Checked and Clear" lists the unmatched rules with check marks, alongside the note that no matched rule is not proof that a message is legitimate.
9. Continuation: the recipient understands that a clean result is a reason to keep verifying, not a guarantee.

6. Visuals, Colors, and Theme

The creative direction is authoritative for this section. The muse is Dieter Rams, and the headline is "Functional clarity on the evidence desk — less, but better." The register is calm authority, forensic honesty, and quiet reassurance: a lab report, not an alarm.

Palette — light mode

Palette — dark mode

Semantic level colours (muted, never neon)

The accent #C2410C is reserved exclusively for matched evidence tape, the risk stamp, and active stage markers. All colours are exposed as CSS variables so the light and dark themes switch together under prefers-color-scheme.

Typography

• Headings: "Bricolage Grotesque", Arial, system-ui, sans-serif at 600–700 weight. Section titles are uppercase with 0.08em tracking at small label sizes. The risk level and score are set at display scale with -0.02em tracking so numbers read as instrument readouts. No italic, no decorative weights.
• Body: "IBM Plex Sans", system-ui, sans-serif.
• Evidence: "IBM Plex Mono", ui-monospace, monospace at 15px with 1.55 line-height.
• Scale: a 1.25 modular scale on a 16px base — 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61px. The display score uses clamp(40px, 9vw, 61px).

Shape language

Sharp-cornered evidence sheets with a hairline 1px border and a 2px top rule in slate-navy. Controls are rounded rectangles with a 6px radius, modelled on Braun hardware buttons: flat, matte, with a subtle 1px inset border rather than shadows. Evidence-tape labels are small rectangles with clipped corners and a slight static rotation between −1.5deg and 1.5deg. The risk stamp is a rotated (−3deg) outlined rectangle with a double rule border, like a rubber stamp impression. No blobs, no pills except status chips, and no drop shadows beyond a single 1px hairline.

Layout

A twelve-column strict grid with 24px gutters and a 1180px maximum content width. On desktop, the left column (7 columns) holds Submit the Evidence, the highlighted message sheet, and Warning Signs; the right column (5 columns) stacks Scam Type, Stage Tracker, Reality Check, What To Do Now, Checked and Clear, Practice, and Self-Test. Every card is a white sheet with a numbered section label (01, 02, 03…) in monospace at the top-left, aligned to a shared baseline. On mobile, the layout is a single column with full-width buttons, sheets bleeding to 16px margins, and the stage tracker stacking vertically with connecting rule lines. Labels and values are set as aligned label/value pairs so the rule engine's arithmetic reads like a datasheet.

Imagery

No photography, no illustration, no gradients. The visual vocabulary is diagrammatic: the CSS shield mark built from clip-path polygons in slate-navy with an accent keyhole; hairline horizontal rules separating data rows; monospace evidence text on a faintly ruled sheet background (a repeating 24px baseline grid at 3% ink); and small geometric stage markers (circle, square, triangle, diamond, bar) for HOOK, TRUST, PRESSURE, PAYMENT, and EXIT. The only "image" is the user's own pasted message rendered as evidence.

7. Signature Design Concept

The first screen is a two-panel evidence desk, not a centred marketing hero.

On the left, spanning roughly 60% of the viewport width at 1280px, sits a white evidence sheet titled SUBMIT THE EVIDENCE in Bricolage Grotesque 600 uppercase with a monospace section number 01. Beneath it, the textarea occupies a 240px-tall ruled field, and beneath that a row of five sample buttons rendered as flat Braun-style controls with monospace labels.

On the right, in the remaining 40%, the risk verdict panel is already populated on load with the Guaranteed Profit sample: a rotated deep-red stamp reading CRITICAL at clamp(28px, 6vw, 44px) in Bricolage Grotesque 700, the score set at clamp(40px, 9vw, 61px) directly beneath it, and a horizontal text progress bar of 24 discrete monospace blocks — filled blocks in accent orange, empty blocks in muted grey — so the score is legible as a count, not just a colour.

The whole composition sits on the pale blue-grey desk with a single 1px slate rule dividing the two panels. Nothing is centred, nothing floats, nothing glows. The signature moves that carry through the rest of the app are the rotated rubber-stamp verdict, the evidence-tape highlights with clipped corners and static rotation, the monospace datasheet arithmetic block for "Why this score?", the numbered evidence sheets on a shared baseline grid, and the five-marker ruled stage tracker.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the two-panel evidence desk — the white "SUBMIT THE EVIDENCE" sheet on the left and the populated risk verdict panel on the right, divided by a single 1px slate rule.
• Input → transformation → outcome thesis: the user's pasted message is the input; the local rule engine transforms it into matched patterns, weights, and a summed score; the outcome is the rotated stamp verdict, the numeric score, and the 24-block progress bar rendered on the right panel. Nothing is fetched, nothing is animated beyond the single entrance.
• Motion vocabulary: restrained and mechanical. Exactly one entrance animation — the analysis result sheet fades and slides up 12px over 220ms with a linear-out easing when a new analysis runs. The stamp is statically rotated at −3deg and never animated. Highlighted evidence tape does not pulse; hovering a tape label raises its 1px border to 2px accent. The progress bar fills in one 400ms linear step.
• Composed first frame: the pale blue-grey desk, the left evidence sheet with its monospace section number 01 and its five flat sample buttons, the right verdict panel already showing the CRITICAL stamp, the score, and the filled progress blocks, and the hairline rule between them.
• Reduced-motion state: under prefers-reduced-motion, all motion is disabled and the final state is visible immediately — the result sheet appears without the fade or slide, and the progress bar is shown already filled.

No 3D or WebGL scene is required or requested for this project.

9. Non-Functional Requirements

NFR-01 — Offline operation (explicit) The app must work fully offline with no external requests. Rationale: the authoritative requirement states the app must work fully offline and make no external requests, and the header advertises NO DATA SENT.

NFR-02 — Single-file packaging (explicit) The entire app must ship as one self-contained HTML file with CSS in a <style> element and JavaScript in a <script> element. Rationale: explicit delivery constraint.

NFR-03 — No frameworks or libraries (explicit) No frameworks, libraries, backends, APIs, databases, wallets, or blockchain calls may be used. Rationale: explicit technology constraint.

NFR-04 — Safe rendering (explicit) User text must be rendered only with textContent, createElement, and appendChild; innerHTML must never be used with user text, and eval and Function must never be used. Rationale: explicit security constraint preventing injection from pasted content.

NFR-05 — Safe regex (explicit) All rule regexes must avoid nested quantifiers and use bounded wildcards such as [\s\S]{0,60}. Rationale: explicit constraint preventing catastrophic backtracking and page hangs.

NFR-06 — Error containment (explicit) Analysis must be wrapped in try/catch, raw errors must never be shown, and no console errors may occur. Rationale: explicit reliability and polish constraint.

NFR-07 — Accessibility (explicit) Proper labels, keyboard navigation, visible focus, aria-live regions, WCAG AA contrast, meaning never conveyed by color alone, and touch-friendly buttons are required. Rationale: explicit accessibility constraint.

NFR-08 — Responsive integrity (explicit) No horizontal scroll at 320, 360, or 390 px, on tablet, or on desktop. Rationale: explicit responsive constraint.

NFR-09 — Reduced motion (explicit) All motion must be disabled under prefers-reduced-motion. Rationale: explicit accessibility constraint.

NFR-10 — Theme support (explicit) Light and dark themes must be driven by CSS variables following prefers-color-scheme. Rationale: explicit theming constraint.

NFR-11 — Storage safety (explicit) Any localStorage use must be wrapped in try/catch. Rationale: explicit constraint ensuring storage unavailability never breaks the app.

NFR-12 — No real crypto handling (explicit) The app must use sample/test data only and must never handle real Bitcoin, keys, or payments. Rationale: explicit scope and safety constraint.

NFR-13 — Deterministic local execution (required_inference) All analysis, scoring, highlighting, practice feedback, and self-test execution must occur locally in the browser with no backend or external service. Rationale: required to make the accepted offline, no-data-sent journey executable.

10. Tech Stack

• Markup: HTML5, one self-contained file.
• Styling: CSS inside a single <style> element, using CSS custom properties for the light and dark themes and prefers-color-scheme for theme selection. No CSS frameworks.
• Scripting: vanilla JavaScript inside a single <script> element. No frameworks, no libraries, no build step.
• Fonts: system font fallback stacks only — headings "Bricolage Grotesque", Arial, system-ui; body "IBM Plex Sans", system-ui; evidence "IBM Plex Mono", ui-monospace, monospace. No web font requests.
• Storage: optional localStorage, used only inside try/catch.
• Runtime: any modern browser, opened from the local filesystem or served as a static file. No server, no backend, no database, no API, no wallet, no blockchain.

11. Assumptions and Constraints

Assumptions

• A-01 [Assumption — not specified by user]: The five sample texts are treated as fixed fixtures whose expected levels are CRITICAL, CRITICAL, CRITICAL, HIGH, and LOW respectively, and rule weights are tuned to satisfy those targets.
• A-02 [Assumption — not specified by user]: The "strongest family" for the scam-type card is the family with the highest total matched weight, with ties broken by the first matched rule in array order.
• A-03 [Assumption — not specified by user]: The compounded yearly return is computed from the detected rate and its stated period, using 365 compounding periods for daily, 52 for weekly, and 12 for monthly claims.
• A-04 [Assumption — not specified by user]: The India Cyber Crime Portal link is a user-initiated navigation only; the app remains fully functional offline without it.
• A-05 [Assumption — not specified by user]: The 24-block progress bar maps the 0–100 score proportionally onto 24 discrete blocks.

Constraints

• C-01: One self-contained HTML file; HTML plus CSS in <style> plus vanilla JS in <script>.
• C-02: No frameworks, libraries, backend, API, database, wallet, blockchain, or external requests.
• C-03: Must work fully offline.
• C-04: Sample/test data only; never handle real Bitcoin, keys, or payments.
• C-05: Never use innerHTML with user text; use textContent, createElement, and appendChild.
• C-06: No eval or Function.
• C-07: Safe regex only — no nested quantifiers; bounded wildcards such as [\s\S]{0,60}.
• C-08: Negations must be ignored — "Never share your seed phrase" and "Do not send Bitcoin" must not trigger rules.
• C-09: No neon, glow gradients, glassmorphism, emoji icons, or generic SaaS/crypto-dashboard look.
• C-10: Simple CSS shield mark; no emoji logo.
• C-11: No horizontal scroll at 320, 360, or 390 px, on tablet, or on desktop.
• C-12: Disable all motion for prefers-reduced-motion.
• C-13: Never show raw errors; wrap analysis in try/catch.
• C-14: Practice mode must have exactly six scenarios.
• C-15: The rule engine must contain 18–20 rules.
• C-16: Textarea maximum is 5000 characters.
• C-17: Score is capped at 100.
• C-18: The India Cyber Crime Portal link must open in a new tab with rel="noopener noreferrer".
• C-19: No console errors.

12. Glossary

• Risk Score — A number from 0 to 100 computed as round(100 × (1 − e^(−sum/45))), capped at 100, where sum is the total of matched rule weights plus any bonus.
• Risk Level — The band derived from the Risk Score: LOW (0–24), MEDIUM (25–47), HIGH (48–71), CRITICAL (72–100).
• Rule — One entry in the local rule engine, carrying an id, label, weight, regex, explanation, tip, family, and stage.
• Weight — The numeric contribution a matched rule adds to the score sum.
• Bonus — The +12 addition to the sum applied when both an urgency rule and a payment rule match.
• Family — The scam category a rule belongs to: Investment, Giveaway, Impersonation, Credential Theft, Phishing, Pressure, Advance Fee, Recovery, Device Takeover, or Payment.
• Stage — One of the five scam phases tracked by the app: HOOK, TRUST, PRESSURE, PAYMENT, EXIT.
• Evidence tape — The small, slightly rotated, clipped-corner label that wraps a matched phrase inside the original message.
• Stamp verdict — The rotated, double-rule outlined rectangle that displays the risk level.
• Reality check — The card that detects a recurring percentage return claim and computes its compounded yearly equivalent.
• Checked and Clear — The list of rules that did not match, shown with check marks and the caveat that a clean result is not proof of legitimacy.
• Seed phrase — A sequence of words that can restore a Bitcoin wallet; sharing it gives away control of the funds.
• Private key — The secret value that authorizes spending from a Bitcoin address.
• Self-test — The control that runs the real analyzer against all five samples and reports PASS/FAIL lines with an aggregate count.