Mission Control UAS Database

What should we do?

Build a Mission Control UAS Database UI for browsing and editing the UAS source records directly in MC.

The primary browse unit should be the company. Pete should scroll a task-list-style company index, click a company, and open a dedicated company page in a new browser tab. That detail page should show and edit the company record, plus its related products, customer-segment context, and evidence in a human-friendly way.

This should replace spreadsheet-first review as the main QC surface for the UAS dataset.

Core product decisions

1. The UI should be called UAS Database, not Lantronix workbench.
2. The main list should be companies only in v1. Do not mix companies, products, customer segments, and evidence together in one index.
3. Products should appear on the company detail page.
4. Customer segments should be blended into the company page as human-readable fit/context, not treated as a separate thing Pete has to browse constantly.
5. Evidence should be shown on the company page in a readable evidence text area / digest, while the structured evidence records remain underneath for traceability.
6. The only Lantronix-specific thing in the UI should be the existing concerns_lantronix checkbox/flag in the data.

Why this needs to exist

The current source-of-truth data is structured well for the system but bad for human review.

Current options are both weak:

• raw JSON files are accurate but painful to scan and edit
• Google Sheets is easy to scroll but bad at nested data, linked records, arrays, enums, and evidence traceability

Pete wants a native Mission Control review surface with this interaction model:

• task-list-style scrolling through companies
• click a company to open a new page in a new tab
• view all relevant related info from that company page
• edit and save directly
• use keyboard next/previous to move through review flow quickly

Naming and scope changes

This should be framed everywhere as UAS Database.

UI copy

Use:

• UAS Database
• Companies
• Products
• Segments
• Evidence
• Lantronix relevance

Do not use:

• Lantronix workbench
• Lantronix records
• Lantronix browser/editor

Code and file naming

Rename implementation-facing paths and artifacts to match the generic product framing.

Recommended targets:

• route: /uas-database
• artifact name: spec_mission_control_uas_database.md
• task title: Build Mission Control UAS Database browser and editor
• data path target: data/uas-database/

Data-path migration

Current path:

• data/lantronix-uas-workbench-phase1/

Target path:

• data/uas-database/

Implementation note:

• migrate the directory name as part of the feature work, or create a compatibility layer first and complete the physical rename in the same implementation track
• keep concerns_lantronix as a field on company records

Goals

1. Make the UAS source data easy to review and edit through a company-first UI.
2. Preserve JSON files as source of truth.
3. Let Pete review one company at a time without losing his place in the browse flow.
4. Show related products, target segments, and evidence in the company page instead of scattering them into separate browsing chores.
5. Support direct editing and save.
6. Add a lightweight QC state so reviewed records are visible and filterable.

Non-goals

1. Do not build a generic schema editor for arbitrary datasets in v1.
2. Do not make products, segments, and evidence equal-weight browse objects on day one.
3. Do not replace the file-based store.
4. Do not build comments, approvals, or multi-user workflow in v1.
5. Do not block the project on perfect schema normalization before shipping the review UI.

Primary user flow

1. Pete opens UAS Database in Mission Control.
2. He sees a compact company list that behaves like the current task list view.
3. He filters the company list by relevance, vertical, QC status, NDAA, or search.
4. He clicks a company name.
5. MC opens that company in a new browser tab.
6. The company page shows:

• editable company fields
• related products
• segment context blended into the page
• readable evidence digest
• structured linked evidence underneath when needed

1. Pete edits fields and clicks Save changes.
2. He uses keyboard next/previous to move through companies without going back to the list manually.
3. The original list tab stays intact so review never loses place.

Information architecture

Navigation

Add a new top-level MC section:

• UAS Database

Primary routes

Recommended v1 routes:

• /uas-database
• /uas-database/companies/[id]

Recommended v2 secondary routes:

• /uas-database/products/[id]
• /uas-database/segments/[id]
• /uas-database/evidence/[id]

Important: v2 secondary routes exist for deep-linking and admin use, but they are not the primary review flow.

UX spec

1. Index page, company list only

The index page should reuse the best parts of Mission Control’s current task list view.

Layout

• full-width page
• sticky filter/search bar
• compact company rows
• one row per company
• company title opens detail page in a new tab

Company row contents

Each company row should show:

• company name
• Lantronix relevance pill from concerns_lantronix
• primary verticals
• ecosystem roles
• NDAA status summary
• short summary preview
• QC checked state
• last updated date
• warning indicator for weak evidence or validation issues

Filters

V1 filters:

• search
• concerns_lantronix
• primary vertical
• ecosystem role
• region
• NDAA profile status / sensitivity
• QC checked / unchecked
• evidence strength
• validation issues present

Sorting

Support:

• updated recently
• alphabetical
• Lantronix relevance first
• QC unchecked first
• strongest evidence first

2. Company detail page

This is the core UI.

Detail page rules

• opens in a new browser tab by default
• full-page view, not a modal
• save controls stay visible
• grouped sections, not raw JSON
• related products, segment context, and evidence are part of the page
• raw JSON is available as an escape hatch, not the main surface

Header

Top of page should include:

• company name
• quick badges: Lantronix relevance, region, NDAA, QC state
• save state: saved / unsaved changes / validation errors
• buttons:
• Save changes
• Revert
• Open raw JSON
• Open website

Keyboard navigation

This should be supported in v1.

When a detail page is opened from a filtered list context, support:

• j / k or arrow down / arrow up for next/previous company
• optional next / previous buttons in the header
• preserve the current filter/sort context so navigation follows the same review order Pete came from

Reason:

• this keeps review in a fast triage flow
• it avoids constant tab thrash and back-button nonsense

3. Company detail page structure

The company page should be organized into sections.

A. Identity

Editable:

• name
• website
• headquarters
• country code
• region
• year founded

B. Relevance and positioning

Editable:

• concerns_lantronix toggle, shown as Lantronix relevance in UI
• summary
• market positioning note
• platform domains
• key use cases

C. Business profile

Editable:

• ecosystem roles
• service capabilities
• primary verticals
• cross-cutting tags
• company scale fields
• channel model

D. Customer segment fit, blended into the company page

Do not force Pete to browse separate segment records for normal review.

Proposed blended treatment:

• show a Target Segments section on the company page
• each linked segment appears as a compact card or expandable row
• each segment block shows:
• segment name
• strategic fit label
• buyer personas
• jobs to be done
• buying criteria
• geography focus
• NDAA sensitivity

Editable from the company page:

• linked target segments
• optional company-specific segment fit note per linked segment, if we add a lightweight sidecar field

Recommendation:

• keep segment records as first-class data underneath
• render them inline on the company page for review convenience
• if needed, add a company-level free-text field like segment_fit_notes so Pete can capture nuance without editing the base segment definition every time

E. Products for this company

Yes, products should be shown on the company page.

Recommended treatment:

• show a Products section under the company summary area
• one row/card per linked product
• each product shows:
• product name
• product class
• platform domains
• target segments
• evidence confidence
• technical positioning summary preview
• clicking a product can open its own detail page in a new tab later, but v1 can allow inline summary + edit drawer if faster

Recommendation:

• v1 should at minimum show products inline on the company page
• product deep pages can come in phase 2

F. Evidence, rendered as readable text plus traceability

Pete does not want to stare at raw evidence-record fields as the main surface.

Proposed model:

• show an Evidence Digest text area on the company page
• this is the human-friendly evidence view and edit surface
• below that, show linked structured sources in a collapsible Traceability section

The digest should support plain text or markdown-style notes and capture things like:

• the core claims we believe
• what source backs them
• what still feels weak
• caveats and contradictions

Recommended field addition:

• evidence_digest or evidence_notes on the company record

Structured evidence should still exist underneath for source linkage, but the company page should make the readable text block the first thing Pete sees.

Traceability sub-section should show:

• source title
• source type
• URL
• confidence
• verification status
• brief claim summary

This gives us both:

• a human-readable evidence surface
• structured source records for integrity and later reporting

G. QC section

Add a lightweight QC section on the company page.

Proposed meaning of the QC flag:

• QC checked means Pete has reviewed this record in the UI
• it does not mean the record is perfect forever
• it does not mean client-ready certification
• it means “a human looked at this and made a deliberate review pass”

Required field:

• qc_checked boolean

Pete can use the existing company notes field for review notes or corrections. No extra QC timestamp/by/notes fields are needed in v1.

UI behavior:

• checkbox: QC checked
• filter: checked / unchecked
• visible badge in list and detail pages

Keep this lightweight. Do not turn it into a workflow system.

Editing model

Human-friendly controls first

Use controls that match the field type:

• text input for short strings
• textarea for summaries, notes, and evidence digest
• select for enums
• multi-select chips for enum arrays
• linked-record picker for target segments and source links
• toggle for booleans
• date input for captured dates and QC timestamps when relevant

Raw JSON fallback

Each company page should include Open raw JSON for advanced inspection.

That is a trust and escape hatch feature, not the primary editing path.

Save behavior

• edits stay local until Save
• Save validates before write
• if validation passes, write back to the JSON file
• if validation fails, show field-level errors
• if the file changed since load, show a conflict warning and require reload or explicit overwrite behavior

Validation rules

Use the existing JSON schemas as the base validation truth, then extend them carefully for the approved new UAS Database UI fields.

At minimum:

• required fields enforced
• enums enforced
• id patterns enforced
• URLs validated
• uniqueness preserved where required

Add qc_checked to the company schema. Use the existing company notes field for review notes and the evidence text field decided for the company page.

Data model and storage

Source of truth

Keep file-based JSON as source of truth.

Target storage root:

• data/uas-database/

Recommended subpaths:

• data/uas-database/records/companies/
• data/uas-database/records/products/
• data/uas-database/records/customer-segments/
• data/uas-database/records/evidence/
• data/uas-database/schema/

Read/write model

Mission Control should read/write through server helpers and API routes.

Recommended helpers:

• lib/uas-database-records.ts
• lib/uas-database-validation.ts
• lib/uas-database-relations.ts

Recommended routes:

• GET /api/uas-database/companies
• GET /api/uas-database/companies/[id]
• PUT /api/uas-database/companies/[id]
• GET /api/uas-database/products/[id]
• GET /api/uas-database/segments/[id]
• GET /api/uas-database/evidence/[id]

Reuse of existing MC patterns

This should reuse Mission Control’s current list/edit posture rather than inventing a second design system.

Strong reuse candidates:

• app/(app)/tasks/page.tsx
• components/tasks/TasksWorkspace.tsx
• components/tasks/TaskListView.tsx
• components/tasks/TaskEditorModal.tsx

Specifically:

• the company index should borrow row density and scan rhythm from TaskListView
• the company detail page should borrow the clean editing posture from TaskEditorModal, but as a full page
• do not use a modal editor for the main review flow

V1 scope

Included

• UAS Database company index page
• company filters and search
• company detail page in new tab
• editable company fields
• inline product section on company page
• blended segment section on company page
• evidence digest plus traceability section on company page
• QC checked state
• keyboard next/previous navigation in review flow
• schema validation
• save back to source JSON

Excluded from v1

• mixed all-records master list
• bulk edit
• comments / approval workflow
• full edit history UI
• generic dataset editor
• polished standalone editors for products, segments, and evidence before the company flow works

Acceptance criteria

1. Pete can open /uas-database and scroll companies in a task-list-style list.
2. The index is company-only, not a mixed record-type list.
3. Clicking a company opens its detail page in a new tab.
4. The company page shows the company data, related products, target segment context, and readable evidence in one place.
5. Pete can edit a company, save changes, refresh, and see the persisted result.
6. Evidence is readable as text, not only as structured source fields.
7. Pete can mark a record QC checked and filter by that state.
8. Pete can move next/previous through the review flow with keyboard navigation.
9. The UI is branded and structured as UAS Database, not Lantronix workbench.

Implementation phases

Phase 1

Ship:

• /uas-database company list
• company detail page
• product section on company page
• blended target-segment section
• evidence digest section
• QC checked
• save flow
• next/previous navigation

Phase 2

Add:

• dedicated product detail pages
• dedicated segment detail pages
• dedicated evidence detail pages
• richer linked-record editing

Phase 3

Add:

• validation summary dashboard
• bulk review helpers
• compare view
• richer conflict handling

Recommendation

Build this as a company-first UAS Database inside Mission Control.

Do not make Pete browse a mixed list of record types. Let him review companies in a task-list-like flow, then pull the related products, segments, and evidence into the company page where they actually matter.

That gives him a review surface that matches how humans think about the data, instead of forcing him to think like the storage schema.

Open questions

1. Should product editing in v1 happen inline on the company page, or be read-only cards that deep-link to product detail pages once phase 2 lands?
2. Do we want evidence_notes and qc_* fields in the core company schema, or as a small sidecar metadata file keyed by company id?
3. Should the segment blend section support company-specific override notes in v1, or wait until phase 2?