System Requirements Document for email-businesses-canada

1. Introduction

email-businesses-canada is a code-based outreach and research toolkit for a self-directed builder working in Canada. The product exists to answer two questions the user asked directly:

1. "Can I write code that I can use to send out email to businesses all over Canada?" — Yes. The product provides working code that composes and sends outreach email to Canadian business recipients.
2. "Can I create code that will allow me to research everything I need about a particular topic without having to look it all up myself?" — Yes. The product provides code that takes a topic and returns consolidated research results in one pass, instead of manual browsing.

The user also asked two enabling questions that the product must answer in-product rather than leave to guesswork:

3. "What can I use to execute the code?" — The product states and supports the execution environment.
4. "What should I need to write the code?" — The product states and supports the authoring prerequisites.

Audience. A solo operator or small team — a technical, information-dense tool for a self-directed builder who values clarity, speed, and honest engineering over marketing gloss. The interface is an operational instrument: recipient lists, send logs, research dossiers, and code snippets, presented with Swiss-grid rigour.

Intent boundary. This is a working toolkit, not a marketing platform. It sends outreach email to Canadian businesses and it researches topics. It does not manage marketing campaigns, CRM pipelines, or social channels, and it does not claim to.

2. System Overview

The product is a first-party web application with four pages, all reachable without an account:

Actors.

• Outreach Operator — composes and sends outreach email to a list of Canadian business recipients.
• Topic Researcher — submits a topic and receives consolidated research results.
• Code Runner / Developer — sets up the environment, writes the code, and runs it.
• External recipients — Canadian businesses that receive outreach email. These are outbound-only recipients, not product users; they never sign in and never see the interface.
• Research sources — external information providers queried by the research code. Provider-owned; the product consumes their results.

Accepted behavior. The product (a) sends email to businesses across Canada, (b) researches a topic in one pass without manual lookup, (c) tells the user what to use to execute the code, and (d) tells the user what is needed to write the code.

Ownership. All four pages are application-owned custom UI. Email delivery to recipients is performed by an external mail provider. Research retrieval is performed against external sources. Neither provider surface is a first-party page.

Narrow exclusions. No account creation, sign-in, or user profile is part of the current product. No CRM, campaign scheduling, drip sequences, A/B testing, analytics dashboards, or social publishing. No blue or indigo anywhere in the interface.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a first-party web application with four pages. The Landing page is the anonymous public entry. Outreach, Research, and Development are working surfaces reachable directly, with no account gate — the user asked for code they can run, not for a hosted account system, and no accepted journey requires durable per-user identity to be privately owned or resumed.

Access ownership. All four pages are application-owned and openly reachable. Email delivery is provider-owned: the product hands a composed message and a recipient list to an external mail provider, which performs the actual delivery. Research retrieval is provider-owned in the same way: the product submits a topic to external sources and consolidates what comes back. The product owns composition, the recipient list, the run state, the send log, and the presentation of results; it does not own the mail transport or the upstream information sources.

Current vs. future. Current scope is exactly the four requirements above: send email to Canadian businesses, research a topic in one pass, state what executes the code, and state what is needed to write it. Anything beyond that — campaign management, contact enrichment, scheduling, multi-user accounts — is out of current scope and is not built.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

Information and state. Anonymous public entry. Explains, before any workflow begins, that this is code that emails businesses across Canada and code that researches any topic in one pass. States the two capabilities and the two enabling answers (what executes the code, what is needed to write it) at a summary level, with the detail living on Development.

Primary actions. Enter Outreach; enter Research; enter Development.

Supporting actions. Read the three labelled capability facts; follow the flush-left primary call to action.

Domain entities. Capability summary (send / research / run); the product name.

Component responsibilities.

• Full-width black top band — pinned to the top, carrying the section title in white uppercase Archivo at 0.12em tracking, acting as a wayfinding stripe.
• Oversized flush-left headline — Archivo 800 at clamp(40px, 8vw, 96px), spanning roughly 9 of 12 columns, reading EMAIL CANADA stacked over RESEARCH ANYTHING.
• 1px black rule beneath the headline, running the full viewport width, with a small red square at its left terminus.
• Three-column ruled fact row — SEND, RESEARCH, RUN, each with a short factual descriptor and a small red geometric marker.
• Solid black rectangular CTA — flush-left under the third column, never centred.
• Diagrammatic line art — a schematic map of Canada with recipient clusters as black dots. Decorative only; carries no readable text.

States.

• Loading — not applicable; the page is static content.
• Empty — not applicable.
• Success — the page renders fully with headline, rule, fact row, and CTA.
• Error — not applicable; no data fetch occurs.
• Recovery — not applicable.

Outreach

Information and state. The recipient list of Canadian businesses, the composed message, the current run state, and the send log. The recipient list renders as a ruled tabular band with alternating 1px top borders, monospace numerals right-aligned, and a red left-edge marker on the currently active row. The send log records each attempt with its outcome.

Primary actions. Add or edit recipient entries; compose the subject and body; start a send run; review the send log.

Supporting actions. Remove a recipient entry; clear the log; re-run a failed send.

Domain entities. Recipient (business name, email address, province/territory, status); Message (subject, body); Send run (start time, progress, outcome); Send log entry (recipient, timestamp, result, failure reason).

Component responsibilities.

• Full-width black top band — section title OUTREACH in white uppercase Archivo.
• Section head — flush-left over a full-width 1px black rule with a small red square at the rule's left terminus.
• Recipient table — ruled bands, alternating 1px top borders, monospace numerals right-aligned, red left-edge marker on the active row.
• Message composer — rectilinear inputs with 1px black borders, 0px radius.
• Send control — solid black rectangle with white uppercase label; the only red-accented action is the active send state.
• Red progress rule — a thin red rule that sweeps left-to-right across the top of the content area during a send run, then settles as a static red line under the section head.
• Send log — ruled tabular band, one row per attempt.

States.

• Loading — the recipient table and log show ruled placeholder bands while data resolves.
• Empty — no recipients yet: the table shows a ruled empty band with a factual instruction to add the first recipient. No log rows: the log shows a ruled empty band.
• Success — the run completes; the progress rule settles static; each log row shows a delivered result.
• Error — a recipient address is malformed, or the mail provider rejects a message: the affected log row shows the failure reason and the run continues for the remaining recipients.
• Recovery — the failed row offers a re-run action; correcting the address and re-running produces a new log row.

Research

Information and state. The submitted topic, the run state, and the consolidated research results with their sources. Sources render as a ruled tabular band with alternating 1px top borders and monospace numerals right-aligned.

Primary actions. Submit a topic; start a research run; read the consolidated result; open a source.

Supporting actions. Re-run a topic; clear the current result.

Domain entities. Topic (the submitted query); Research run (start time, progress, outcome); Result (consolidated findings for the topic); Source (title, locator, retrieval timestamp).

Component responsibilities.

• Full-width black top band — section title RESEARCH in white uppercase Archivo.
• Section head — flush-left over a full-width 1px black rule with a small red square at the rule's left terminus.
• Topic input — rectilinear field with 1px black border, 0px radius.
• Run control — solid black rectangle with white uppercase label.
• Red progress rule — sweeps left-to-right during a research run, then settles static under the section head.
• Result body — flush-left ragged-right Archivo, 16–18px at 1.55 line-height.
• Source table — ruled bands, alternating 1px top borders, monospace numerals right-aligned.
• Geometric composition — concentric circles or a ruled grid standing in for research structure. Decorative only.

States.

• Loading — the progress rule sweeps; the result area shows ruled placeholder bands.
• Empty — no topic submitted: the result area shows a ruled empty band with a factual instruction to enter a topic.
• Success — the consolidated result renders with its source table.
• Error — a source is unreachable or returns nothing usable: the result renders with the sources that did resolve, and the unreachable source is listed with its failure reason.
• Recovery — re-running the topic retries the failed sources and replaces the result.

Development

Information and state. The setup guidance, the code authoring surface, the execution guidance, and the run controls for the outreach and research code. Code blocks are treated as primary imagery: black ground, white Archivo Mono, numbered lines in the left gutter, with a red vertical rule marking the executable region.

Primary actions. Read what is needed to write the code; read what to use to execute the code; author or paste code; run the outreach code; run the research code.

Supporting actions. Copy a code block; clear the editor; view the last run output.

Domain entities. Prerequisite (a named requirement for writing the code); Execution target (a named environment for running the code); Code block (language, numbered lines, executable region); Run output (stdout/stderr, exit status, timestamp).

Component responsibilities.

• Full-width black top band — section title DEVELOPMENT in white uppercase Archivo.
• Section head — flush-left over a full-width 1px black rule with a small red square at the rule's left terminus.
• Prerequisites list — ruled bands naming what is needed to write the code.
• Execution guidance list — ruled bands naming what to use to execute the code.
• Code editor — rectilinear, 1px black border, 0px radius, monospace.
• Code block renderer — black ground, white Archivo Mono, numbered left gutter, red vertical rule marking the executable region.
• Run controls — solid black rectangles with white uppercase labels, one for outreach and one for research.
• Output panel — ruled band showing stdout/stderr and exit status.
• Flow diagram — a schematic of the outreach pipeline in diagrammatic line art. Decorative only.

States.

• Loading — the guidance lists and output panel show ruled placeholder bands.
• Empty — no code authored: the editor shows a ruled empty band. No run yet: the output panel shows a ruled empty band.
• Success — a run completes; the output panel shows stdout and a zero exit status.
• Error — a run fails: the output panel shows stderr and the non-zero exit status, with the failing line marked.
• Recovery — correcting the code and re-running replaces the output panel contents.

3. Functional Requirements

FR-1 — Send email to businesses across Canada

As an Outreach Operator I should compose an outreach message and send it to a list of Canadian business recipients so that outreach messages actually go out to the intended business contacts.

• Provenance: explicit
• Trigger / input: The operator adds recipient entries (business name, email address, province/territory) and composes a subject and body on Outreach.
• Observable result: Each recipient entry receives the composed message through the external mail provider; the send log records one row per attempt with recipient, timestamp, and result.
• Access state: Openly reachable; no account required.
• Material failure / recovery: A malformed address or a provider rejection marks that log row with the failure reason while the run continues for the remaining recipients; the operator corrects the address and re-runs, producing a new log row.
• Continuation: The operator reviews the send log and re-runs any failed rows.
• Indispensable participant: The Canadian business recipient receives the message. This is an outbound-only external recipient, not a product user; its side of the lifecycle is receipt of the delivered message, observable to the operator as a delivered log entry.

FR-2 — Research a topic in one pass

As a Topic Researcher I should submit a topic and receive consolidated research results so that a topic can be researched in one pass instead of manual browsing.

• Provenance: explicit
• Trigger / input: The researcher enters a topic on Research and starts a run.
• Observable result: A consolidated result renders with a source table listing each source's title, locator, and retrieval timestamp.
• Access state: Openly reachable; no account required.
• Material failure / recovery: If a source is unreachable or returns nothing usable, the result still renders with the sources that resolved, and the unreachable source is listed with its failure reason; re-running retries the failed sources.
• Continuation: The researcher reads the result and opens individual sources.
• Indispensable participant: The external research sources are provider-owned; the product submits the topic and consolidates what they return. No additional human participant is affected.

FR-3 — State what to use to execute the code

As a Code Runner / Developer I should see what to use to execute the code so that I can run the outreach and research code.

• Provenance: explicit
• Trigger / input: The developer opens Development.
• Observable result: An execution guidance list names the environment used to run the code, and run controls for the outreach code and the research code are present.
• Access state: Openly reachable; no account required.
• Material failure / recovery: If a run fails, the output panel shows stderr and the non-zero exit status with the failing line marked; correcting the code and re-running replaces the output.
• Continuation: The developer runs the outreach code or the research code and reads the output panel.
• Indispensable participant: None beyond the initiator.

FR-4 — State what is needed to write the code

As a Code Runner / Developer I should see what is needed to write the code so that I can author it.

• Provenance: explicit
• Trigger / input: The developer opens Development.
• Observable result: A prerequisites list names each requirement for writing the code, and a code editor is available for authoring or pasting code.
• Access state: Openly reachable; no account required.
• Material failure / recovery: Not applicable to reading the guidance; authoring errors surface through the run output panel per FR-3.
• Continuation: The developer authors code in the editor and proceeds to run it.
• Indispensable participant: None beyond the initiator.

FR-5 — Run the outreach and research code from the product

As a Code Runner / Developer I should run the outreach code and the research code from Development so that the two capabilities can be executed without leaving the product.

• Provenance: required_inference
• Rationale: The user asked what to use to execute the code and what is needed to write it; a stated execution environment is only usable if the code can actually be run from the surface that states it.
• Trigger / input: The developer selects the outreach run control or the research run control.
• Observable result: The output panel shows stdout and the exit status for the selected run.
• Access state: Openly reachable; no account required.
• Material failure / recovery: A non-zero exit shows stderr with the failing line marked; correcting the code and re-running replaces the output.
• Continuation: The developer reads the output and either corrects the code or returns to Outreach / Research to use the result.
• Indispensable participant: None beyond the initiator.

FR-6 — Understand the product before starting a workflow

As an Outreach Operator, Topic Researcher, or Code Runner / Developer I should understand from the public entry what the product does and how to begin so that I can choose the right workflow.

• Provenance: required_inference
• Rationale: The Landing page is the anonymous public entry; it must explain the code-based outreach and topic-research product before the user begins a workflow.
• Trigger / input: The user opens Landing.
• Observable result: The headline, the three labelled capability facts (SEND, RESEARCH, RUN), and the flush-left primary call to action render.
• Access state: Anonymous; no account required.
• Material failure / recovery: Not applicable; the page is static content.
• Continuation: The user enters Outreach, Research, or Development.
• Indispensable participant: None beyond the initiator.

4. User Personas

Outreach Operator

Product context. A solo operator or small-team member who wants to reach Canadian businesses by email using code they control, rather than a hosted marketing platform. They work from a recipient list they maintain themselves and they want to see exactly what was sent and what happened.

Primary goal. Compose an outreach message and get it delivered to the intended Canadian business contacts.

Distinct accepted responsibilities. Maintains the recipient list of Canadian businesses; composes the subject and body; starts the send run; reads the send log; re-runs failed rows. This is a delivery-and-verification responsibility — the operator's work is judged by whether messages actually arrived, not by how the message was drafted.

Relevant inputs or decisions. Recipient entries (business name, email address, province/territory); the message subject and body; the decision to start a run; the decision to re-run a failed row.

Interactions with other accepted participants. Hands the composed message and recipient list to the external mail provider, which performs delivery. The Canadian business recipients receive the message; they are outbound-only and never interact with the interface. The operator may consult Development to run the outreach code.

Observable success. The send log shows a delivered result for each intended recipient, and any failure is visible with its reason and recoverable.

Topic Researcher

Product context. A self-directed builder who needs to understand a topic without manually browsing source after source. They want one submission to produce one consolidated result they can read and cite.

Primary goal. Research a topic in one pass instead of looking it all up manually.

Distinct accepted responsibilities. Submits the topic; starts the research run; reads the consolidated result; opens individual sources; re-runs a topic when a source failed. This is a synthesis-and-verification responsibility — the researcher's work is judged by whether the consolidated result covers the topic and whether its sources are traceable.

Relevant inputs or decisions. The topic text; the decision to start a run; the decision to re-run after a source failure; which sources to open.

Interactions with other accepted participants. The product submits the topic to external research sources, which are provider-owned; the researcher consumes what they return. The researcher may consult Development to run the research code.

Observable success. A consolidated result renders with a source table listing each source's title, locator, and retrieval timestamp, and any unreachable source is named with its failure reason.

Code Runner / Developer

Product context. The same self-directed builder wearing a technical hat: they need to know what to install and what to run, and they want to author and execute the code from the product rather than from scattered notes.

Primary goal. Set up the environment, write the code, and run it so that the outreach and research code can be authored and executed.

Distinct accepted responsibilities. Reads the prerequisites for writing the code; reads the execution guidance; authors or pastes code in the editor; runs the outreach code and the research code; reads stdout, stderr, and exit status; corrects and re-runs. This is an environment-and-execution responsibility — the developer's work is judged by whether the code runs and produces usable output.

Relevant inputs or decisions. The prerequisites list; the execution guidance list; the code in the editor; the decision to run outreach or research; the decision to correct and re-run.

Interactions with other accepted participants. Produces the code that the Outreach Operator and the Topic Researcher use. Does not interact with external recipients or research sources directly.

Observable success. A run completes with a zero exit status and readable stdout, or a failure shows stderr with the failing line marked and is recoverable by correction and re-run.

5. Core User Flows

Flow 1 — Outreach Operator sends email to Canadian businesses

1. The operator opens Landing and reads the headline and the three labelled facts (SEND, RESEARCH, RUN).
2. The operator selects the flush-left primary call to action and enters Outreach.
3. The operator adds recipient entries — business name, email address, province/territory — into the recipient table. Each entry appears as a ruled band with monospace numerals right-aligned.
4. The operator composes the subject and body in the rectilinear composer.
5. The operator selects the send control. The thin red progress rule sweeps left-to-right across the top of the content area.
6. The product hands the composed message and the recipient list to the external mail provider, which performs delivery to each Canadian business recipient.
7. Observable result: the progress rule settles as a static red line under the section head, and the send log shows one row per attempt with recipient, timestamp, and result.
8. Failure and recovery: if an address is malformed or the provider rejects a message, that log row shows the failure reason while the run continues for the remaining recipients. The operator corrects the address and re-runs, producing a new log row.
9. Continuation: the operator reviews the send log and re-runs any remaining failed rows, or moves to Development to run the outreach code directly.

Flow 2 — Topic Researcher researches a topic in one pass

1. The researcher opens Landing and reads the headline and the three labelled facts.
2. The researcher selects the primary call to action and enters Research.
3. The researcher enters a topic in the rectilinear topic field.
4. The researcher selects the run control. The thin red progress rule sweeps left-to-right across the top of the content area.
5. The product submits the topic to external research sources, which are provider-owned, and consolidates what they return.
6. Observable result: the consolidated result renders flush-left ragged-right, and the source table lists each source's title, locator, and retrieval timestamp as ruled bands with monospace numerals right-aligned.
7. Failure and recovery: if a source is unreachable or returns nothing usable, the result still renders with the sources that resolved, and the unreachable source is listed with its failure reason. The researcher re-runs the topic, which retries the failed sources and replaces the result.
8. Continuation: the researcher opens individual sources, or moves to Development to run the research code directly.

Flow 3 — Code Runner / Developer learns what is needed and what to use

1. The developer opens Landing and reads the headline and the three labelled facts.
2. The developer selects the primary call to action and enters Development.
3. The developer reads the prerequisites list, which names each requirement for writing the code.
4. The developer reads the execution guidance list, which names the environment used to run the code.
5. Observable result: the developer knows what to install and what to run, and the code editor is available.
6. Continuation: the developer authors or pastes code in the editor.

Flow 4 — Code Runner / Developer authors and runs the code

1. The developer is on Development with the prerequisites and execution guidance read.
2. The developer authors or pastes code into the rectilinear editor, or copies a code block rendered on black ground with white Archivo Mono, numbered lines in the left gutter, and a red vertical rule marking the executable region.
3. The developer selects the outreach run control or the research run control.
4. Observable result: the output panel shows stdout and the exit status for the selected run.
5. Failure and recovery: a non-zero exit shows stderr with the failing line marked. The developer corrects the code and re-runs, which replaces the output panel contents.
6. Continuation: the developer returns to Outreach to send the message, or to Research to read the consolidated result.

6. Visuals, Colors and Theme

Muse: Josef Müller-Brockmann. Headline direction: Swiss grid rigour for bulk Canadian outreach and automated topic research.

The register is confident, methodical, no-nonsense craft. A strict modular grid, flush-left ragged-right grotesque type, and one pure signal colour make a dense operational interface legible and distinctive — nothing decorative, everything placed.

Colour tokens — light mode

Proportion: ~80% paper/white, ~15% black type and rules, ~5% red. No blue anywhere. No gradient.

Typography

• Headings: Archivo — grotesque, flush-left ragged-right, tight tracking -0.02em, heavy 700–800 weights at large sizes; small-caps and uppercase for labels and section markers; strict hierarchy through weight and rule placement rather than many sizes.
• Body: Archivo.
• Scale: 1.25 modular — 64 / 48 / 32 / 24 / 18 / 16 / 14.
• Display headline: clamp(40px, 8vw, 96px).
• Section heads: 32–48px.
• Body: 16–18px with 1.55 line-height.
• Labels: 12–13px uppercase, 0.08em tracking.
• Code: Archivo Mono.

Shape language

Rectilinear only. Hard 0px corners on cards, inputs, and buttons. Thin 1px black rules as the primary structural element — horizontal rules under every section head, vertical column rules in the grid. Geometric shapes (circles, squares, quarter-arcs) used as diagrammatic content, never as decoration. Controls are rectangles with 1px black borders; the primary button is a solid black rectangle with a white uppercase label.

Layout

A visible 12-column modular grid with generous outer margins (24px mobile, 48px tablet, 80px desktop) and consistent 24px gutters. Asymmetric balance: content blocks span 7–8 columns, metadata and controls sit in a 3–4 column right rail. Sections separated by full-width 1px black rules. Tabular alignment for recipient lists, send logs, and research sources — every row a ruled band. Flush-left everything; no centring except single-figure diagrams. At 375px the grid collapses to a single column with the same ruled rhythm.

Imagery

Diagrammatic line art only: schematic maps of Canada with recipient clusters as black dots, flow diagrams of the outreach pipeline, monospace code blocks as first-class imagery, and geometric compositions (concentric circles, ruled grids) standing in for research structure. No photography, no illustration for its own sake, no 3D renders.

Readable text and controls

Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The poster entry. The public entry reads as a poster, not a SaaS hero.

A full-width black band is pinned across the top of the viewport, carrying the section title in white uppercase Archivo at 0.12em tracking — a wayfinding stripe rather than a nav bar. Below it, on the warm off-white ground, an oversized flush-left headline set in Archivo 800 at clamp(40px, 8vw, 96px) spans roughly 9 of 12 columns, with the words EMAIL CANADA stacked over RESEARCH ANYTHING. The dominant element is the type itself; there is no image, no gradient, no blob.

Beneath the headline, a 1px black rule runs the full viewport width with a small red square at its left terminus — the recurring structural motif that appears on Landing, Outreach, Research, and Development. Under the rule, a three-column ruled row of labelled facts — SEND, RESEARCH, RUN — each with a short factual descriptor and a small red geometric marker. A solid black rectangular CTA sits flush-left under the third column, never centred.

The composition is asymmetric and rectilinear: hard 0px corners, 1px black rules doing all the structural work, one signal red used only for state and structure. It recomposes accepted content only — the two capabilities and the two enabling answers — and introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

The direction specifies restrained, mechanical motion with flat hero dimensionality, so the interaction model is Static and the tempo is restrained.

Landing Hero Motion Brief

• Focal subject: The oversized flush-left headline EMAIL CANADA / RESEARCH ANYTHING in Archivo 800, with the 1px black rule and its red left-terminus square beneath it.
• Input → transformation → outcome thesis: On load, each ruled section fades and rises once — a single 200ms fade-and-rise, staggered 60ms — so the poster assembles itself in reading order and then holds still. No input is required; the transformation is the page settling into its final composition.
• Motion vocabulary: Restrained and mechanical. State changes are instant with a 120ms linear opacity/border swap; no easing theatrics, no bounce, no parallax. Reveal-on-scroll is a single 200ms fade-and-rise of each ruled section, staggered 60ms.
• Composed first frame: The black top band is already in place; the headline, the 1px rule with its red square, the three-column fact row, and the flush-left black CTA are all present at their final positions. The first frame is the finished poster, not a partial one.
• Reduced-motion state: With prefers-reduced-motion, the fade-and-rise and the stagger are removed entirely; the poster renders in its final composed state immediately. The red progress rule on Outreach and Research stops sweeping and shows as a static red line under the section head.

The one purposeful loop

A single thin red progress rule sweeps left-to-right across the top of the content area during any send or research run, then settles as a static red line under the section head. This is the only motion in the product. With prefers-reduced-motion it does not sweep; it appears as the settled static line.

9. Non-Functional Requirements

• NFR-1 — No blue or indigo. The palette contains no blue or indigo; red (#E63312) is the only accent. Provenance: explicit (creative direction). Rationale: the direction forbids blue and the generic indigo/blue-on-white SaaS template.
• NFR-2 — Rectilinear geometry. Hard 0px corners on cards, inputs, and buttons; no rounded corners, pill buttons, soft shadows, or glass surfaces. Provenance: explicit (creative direction).
• NFR-3 — Flush-left composition. No centred headlines, centred CTAs, or symmetric hero compositions. Provenance: explicit (creative direction).
• NFR-4 — No decorative imagery. No gradient blobs, decorative illustration, stock photography, or 3D renders. Imagery is diagrammatic line art only. Provenance: explicit (creative direction).
• NFR-5 — No bouncy or parallax motion. No elastic motion, no scroll-jacking. Provenance: explicit (creative direction).
• NFR-6 — Readable text and controls stay whole. At 375px, 768px, and 1280px, headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container, wrapping or scaling to fit; no other element covers any part of them. Provenance: explicit (creative direction).
• NFR-7 — Reduced-motion support. With prefers-reduced-motion, the fade-and-rise and stagger are removed and the red progress rule shows as a static line. Provenance: explicit (creative direction).
• NFR-8 — Factual interface copy. No marketing adjectives or hype copy in the interface; labels are factual and terse. Provenance: explicit (creative direction).
• NFR-9 — Tabular alignment. Recipient lists, send logs, and research sources render as ruled tabular bands with alternating 1px top borders and monospace numerals right-aligned. Provenance: explicit (creative direction).
• NFR-10 — Provider-owned delivery and retrieval. Email delivery is performed by an external mail provider and research retrieval by external sources; the product owns composition, run state, logs, and result presentation. Provenance: explicit (delivery shape: external recipients).

10. Tech Stack

• Frontend: React — the product is a first-party web application with four pages and a dense operational interface. [Default — not specified by user]
• Backend: Python / FastAPI — serves the outreach composition and send orchestration, the research submission and consolidation, and the code-run endpoints. [Default — not specified by user]
• Storage: A relational store for recipient entries, send log rows, research runs, results, and sources. [Default — not specified by user]
• Email delivery: An external mail provider, provider-owned, performing the actual send. Provenance: explicit (external recipients).
• Research retrieval: External research sources, provider-owned, queried by the research code. Provenance: explicit.
• Containerization: Docker / docker-compose for local execution of the outreach and research code. [Default — not specified by user]
• Kubernetes: Not included; deployment does not require it at this scope. [Default — not specified by user]

11. Assumptions and Constraints

• A-1. The product is a first-party web application with exactly four pages: Landing, Outreach, Research, and Development. No additional pages are added.
• A-2. All four pages are openly reachable with no account, sign-in, or profile. No accepted journey requires durable per-user identity to be privately owned or resumed.
• A-3. Email delivery is performed by an external mail provider; the product does not own the mail transport.
• A-4. Research retrieval is performed against external sources; the product does not own the upstream information sources.
• A-5. Canadian business recipients are outbound-only external recipients. They never sign in and never see the interface.
• A-6. The recipient list is maintained by the Outreach Operator; the product does not enrich or discover contacts.
• A-7. The prerequisites list and the execution guidance list name concrete requirements and environments; the specific named items are supplied by the implementation and are not fixed by this document.
• A-8. No CRM, campaign scheduling, drip sequences, A/B testing, analytics dashboards, or social publishing is in current scope.
• A-9. The creative direction is authoritative for palette, typography, shape, layout, imagery, and motion. No blue or indigo appears anywhere.
• A-10. The red progress rule is the only motion in the product; all other state changes are instant 120ms linear opacity/border swaps.

12. Glossary

• Outreach Operator — The persona who composes and sends outreach email to a list of Canadian business recipients.
• Topic Researcher — The persona who submits a topic and receives consolidated research results.
• Code Runner / Developer — The persona who sets up the environment, writes the code, and runs it.
• Recipient — A Canadian business entry in the outreach list, identified by business name, email address, and province/territory.
• Send run — A single execution of the outreach send across the current recipient list.
• Send log — The ruled tabular record of every send attempt, one row per recipient, with timestamp, result, and failure reason.
• Research run — A single execution of the research code against a submitted topic.
• Result — The consolidated findings produced for a submitted topic.
• Source — An external information provider entry listed with title, locator, and retrieval timestamp.
• Prerequisite — A named requirement for writing the code, listed on Development.
• Execution target — A named environment for running the code, listed on Development.
• Executable region — The portion of a code block marked by a red vertical rule, indicating the code that runs.
• Progress rule — The thin red rule that sweeps left-to-right during a send or research run, then settles as a static red line under the section head.
• Wayfinding stripe — The full-width black band pinned to the top of every page, carrying the section title in white uppercase Archivo at 0.12em tracking.