# Part Beacon — Operating Framework

## Brand architecture

**Part Beacon** is the parent service: a global parts aggregator and sourcing-intelligence platform. Helicopter/aviation parts remain the first vertical and proof market, but the brand is deliberately broad enough for industrial, marine, electronics, equipment, automotive, and other hard-to-find parts categories.


## 1. Lead domino

The first high-leverage move is **demand capture before outreach**.

If Part Beacon collects real wanted-part demand first, every future supplier conversation becomes sharper:

- “Do you sell hard-to-find parts?” becomes “Do you have this Bell 206 gearbox / R44 blade / RR300 component?”
- vague browsing becomes structured match work;
- every request improves search vocabulary, translation patterns, and supplier scoring;
- public site traffic becomes a lead-generation loop rather than a static inventory page.

## 2. System architecture

### Layer A — Public demand-capture surface

Purpose: make it easy for a user to tell us what they need.

Components:

- homepage and inventory-first layout;
- wanted-part alert form;
- part/tag/photo upload;
- OCR text field;
- consent checkbox;
- safety disclaimers;
- public-safe inventory summaries.

Rules:

- must be mobile-friendly;
- must never expose source-linked private data;
- must not imply verified airworthiness;
- must optimize for quick part clue submission.

### Layer B — Private intake store

Purpose: preserve submitted demand in a structured, reviewable format.

Components:

- `wanted-alert-signups.jsonl`;
- `part-photo-intake.jsonl`;
- uploaded photo references;
- OCR tokens;
- hashed IP/user-agent metadata for abuse review;
- consent state.

Rules:

- private by default;
- no public indexing;
- no automatic outreach;
- keep enough fields to generate a later RFQ packet.

### Layer C — Supplier/source discovery layer

Purpose: continuously find new supply leads.

Daily job must:

- search multiple languages;
- identify new supplier websites;
- collect public listing facts;
- translate useful non-English listings into English;
- suppress source links from public output;
- write private source-linked review artifacts;
- report only real new leads, updates, or blockers.

Suggested source categories:

- specialty dismantlers;
- aviation surplus dealers;
- parts brokers;
- auction sites;
- military/government surplus;
- MRO shops with inventory pages;
- regional marketplaces;
- non-English supplier directories.

### Layer D — Inventory intelligence layer

Purpose: normalize supply into comparable records.

Each listing/source should become:

- aircraft/model relevance;
- part/component category;
- language/source country;
- translated English title/description;
- price if available;
- location;
- risk/verification notes;
- public-safe notes;
- private source URL;
- confidence score.

### Layer E — Matching layer

Purpose: connect demand to supply without sending anything externally.

Matching signals:

- exact part number;
- normalized part number fragments;
- OEM/platform model;
- component family;
- OCR token overlap;
- urgency;
- geographic fit;
- price/budget clues;
- supplier credibility.

Outputs:

- internal match queue;
- reasons for each match;
- confidence score;
- next recommended action;
- review status.

No match should trigger customer/supplier contact without approval.

### Layer F — RFQ / buyer-alert preparation layer

Purpose: prepare human-review packets for later approved outreach.

RFQ packet should include:

- wanted part and model;
- urgency;
- photos/OCR tokens;
- acceptable alternates;
- documentation required;
- buyer constraints;
- supplier/source notes;
- draft message;
- approval checkbox/status.

Rules:

- draft-first;
- Simon approval required before send;
- preserve BCC/copy rules if email is involved;
- no claim of availability until supplier confirms.

## 3. Public/private split

| Area | Public | Private |
|---|---|---|
| Inventory summary | Yes | Yes |
| Source URL | No | Yes |
| Seller contact | No | Yes, protected |
| Buyer contact | No | Yes, protected |
| OCR/photo refs | No | Yes |
| Match queue | No | Yes |
| RFQ drafts | No | Yes |
| Translation summaries | Yes, source-safe | Yes, source-linked |

## 4. Daily operating rhythm

### 06:30 Pacific — discovery cron

Run the daily Heli job:

1. search for new supplier websites and listings in multiple languages;
2. translate non-English discoveries to English;
3. identify genuinely new source domains;
4. update private lead/review artifacts;
5. update public-safe inventory only when safe;
6. deploy public files only after validation;
7. notify Simon only for real discoveries, updates, deploys, or blockers.

### During build sessions

Focus order:

1. keep public UX clear and mobile-friendly;
2. improve demand capture;
3. improve internal review queue;
4. improve supplier/source discovery;
5. improve RFQ preparation;
6. only then consider monetization/outreach.

## 5. Review statuses

Use these statuses for wanted alerts and match candidates:

- `new` — captured but not reviewed;
- `needs_cleanup` — OCR or user text needs normalization;
- `candidate_match` — possible source/listing match found;
- `qualified_match` — human reviewed and plausible;
- `rfq_draft_ready` — draft packet exists but unsent;
- `approved_for_outreach` — Simon approved exact recipient/copy;
- `contacted` — outreach sent;
- `closed_won` — opportunity succeeded;
- `closed_lost` — no path;
- `dismissed` — bad match/spam/irrelevant.

## 6. Scoring model

Initial match score should be simple and explainable:

- +60 exact normalized part-number match;
- +35 strong OCR token match;
- +25 aircraft/model match;
- +20 component family match;
- +15 same region / practical shipping region;
- +15 urgent/AOG priority;
- +10 credible supplier/domain;
- -30 missing price and weak details;
- -40 high-risk ambiguous listing;
- -100 public/private safety violation.

Every score must include human-readable reasons.

## 7. Monetization paths later

Do not implement these until the match/review loop is working.

Potential experiments:

1. concierge urgent/AOG sourcing fee;
2. paid saved-search alerts;
3. supplier listing placement;
4. private broker intelligence report;
5. commission/referral arrangement;
6. shop/operator subscription for hard-to-find inventory watch.

## 8. Build sequence from here

### Next 1–2 sessions

- Create internal supplier/source registry.
- Create match queue script reading wanted alerts + source-safe/private listings.
- Output review queue as Markdown/JSON/HTML.
- Add translated-source fields to daily lead artifacts.

### Next 3–5 sessions

- Add protected operator dashboard for wanted alerts and matches.
- Add RFQ packet generator.
- Add public-safe supplier category pages if useful.
- Improve OCR token extraction and alternate-part handling.

### Later

- Approved outbound workflows.
- Supplier upload/intake form.
- Buyer alert digests.
- Monetization tests.


## 9. Subscription operating flow

### Free weekly inventory list

- Public/source-safe inventory.
- Weekly refresh cadence.
- No source URLs exposed.
- Designed for general browsing and SEO discovery.

### Daily inventory subscription

- Daily refreshed source-safe inventory.
- Multilingual supplier/listing discovery.
- English translated summaries.
- Billing status during launch: `free_trial_no_payment_due`.

### Part sourcing subscription

- User submits watched aircraft, part number, component family, urgency, and contact.
- System stores the demand privately.
- Daily discovery job compares new sources/listings against watched demand.
- Human review qualifies any match.
- Subscriber notification is prepared or sent only through an approved notification workflow.

Payment setup remains separate from signup during the three-month launch period. Canadian dollars and Bitcoin are supported later, but full BTC destination details should remain private/account-gated.

## 10. Notification rule

A subscriber alert should mean: “we found a credible sourcing lead worth reviewing,” not “this part is verified/certified/airworthy.” Every alert must preserve the safety boundary that condition, tags, traceability, certification, and airworthiness require independent verification.

## Photo-to-watchlist functionality

Part Beacon supports a core workflow: user uploads a photo of a part, tag, plate, box, invoice, or component card; browser OCR extracts likely part/model/serial tokens; the user confirms or edits the extracted text; then the record is stored as a private watched-parts item. The OCR result is an identification aid only and must not be treated as verified part identity, certification, condition, or airworthiness.

Backend records are split into:
- private photo/OCR intake for the uploaded image and extracted tokens;
- private wanted-parts/watchlist record for monitoring and future match notification.