docs: define Phase 6A commercial product architecture

docs/product/COMMERCIAL_DECISION_GATES.md

@@ -0,0 +1,88 @@
+# ArchaeoAI commercial decision gates
+
+## Rule
+
+Every gate starts **NOT COMPLETED**. Evidence and an accountable decision must be recorded; absence
+of a concern is not approval. A gate may be `GO`, `GO WITH CONDITIONS`, or `NO-GO`. A later gate
+cannot override an unresolved blocker in an earlier gate.
+
+## Gate A — Scientific integrity
+
+Confirm claims remain limited to E001’s documented bowl-barrow terrain versus matched
+`unlabelled_background`, evaluated geographies, and stated uncertainty. Scores remain terrain-
+pattern similarity, not archaeological probability. No discovery, absence, clearance, universal
+generalization, or automatic professional determination is implied.
+
+**Minimum evidence:** claims-register audit, frozen-artifact diff, terminology review, and
+documented confirmation that the spent external test was not reused.
+
+## Gate B — Phase 5E review
+
+Appropriate external reviewers examine security, privacy, archaeological/scientific workflow, and
+licensing/data/model issues using the Phase 5E checklist. Substantive findings receive documented
+resolution or an explicitly accepted residual risk appropriate to the intended deployment.
+
+**Current state:** **NOT COMPLETED.** Phase 6A does not complete it or authorize Phase 5F.
+
+## Gate C — Data licensing
+
+Verify commercial-use, hosting, transformation, derived-output, attribution, redistribution, and
+deletion rights for every proposed data source and customer-supplied input. Resolve jurisdiction,
+contract, and source-version differences.
+
+**Stop if:** a required right or attribution obligation is unclear or incompatible.
+
+## Gate D — Model/IP
+
+Establish ownership, authority to use commercially, distribution restrictions, approved runtime
+location, artifact format, provenance, integrity/state verification, and protection/support policy.
+
+**Stop if:** ownership or redistribution/runtime authority is unclear, or safe loading cannot be
+demonstrated.
+
+## Gate E — Real-input authorization
+
+For any pilot, record project purpose, data provider, rights/consent, geographic scope, responsible
+organization, privacy/retention terms, and ethical authority before admission.
+
+**Stop if:** authorization is missing, overly broad, unverifiable, or conflicts with archaeological
+sensitivity.
+
+## Gate F — Professional workflow review
+
+At least one appropriate external domain professional reviews the intended user journey,
+terminology, evidence ladder, review burden, report, and escalation process. Their role, scope,
+conflicts, limitations, findings, and dispositions must be recorded without implying endorsement.
+
+**Current state:** no completion is claimed by this design.
+
+## Gate G — Pilot authorization
+
+Only after Gates A–F are sufficiently resolved may the owner separately authorize a bounded pilot.
+The decision must name the deployment, organization, users, inputs, model, limits, monitoring,
+retention, support, stop conditions, and success criteria. A pilot is not general release.
+
+## Gate H — Public/SaaS decision
+
+A local/private pilot does not authorize public SaaS. Internet access, uploads, multitenancy,
+central storage, telemetry, public interfaces, scaling, incident response, and abuse controls need
+a separate architecture, threat/privacy review, professional review, and explicit owner approval.
+
+## Decision record template
+
+- Gate and date:
+- Decision: `GO` / `GO WITH CONDITIONS` / `NO-GO`
+- Accountable owner:
+- Reviewers and scope (no endorsement implied):
+- Evidence reviewed:
+- Findings and unresolved risks:
+- Required actions, owners, and deadlines:
+- Deployment or activity explicitly authorized:
+- Activities explicitly not authorized:
+- Re-review trigger:
+
+## Current authorization boundary
+
+Phase 6A authorizes documentation and architecture discussion only. It authorizes no model loading,
+real terrain processing, customer-data storage, pilot, Phase 5F work, public interface, deployment,
+commercial claim, or candidate publication.

docs/product/COMMERCIAL_MVP_REQUIREMENTS.md

@@ -0,0 +1,101 @@
+# ArchaeoAI commercial MVP requirements
+
+## Status
+
+This document specifies a possible future MVP. It does not authorize implementation, model
+execution, real-data ingestion, a pilot, Phase 5F, or public access.
+
+## Bounded user journey
+
+1. An authorized user creates a project with a defined purpose and accountable organization.
+2. The user accepts applicable data, privacy, retention, and acceptable-use terms.
+3. The user supplies terrain and project inputs they are authorized to process.
+4. The system validates identity, permission, format, CRS, dimensions, resolution, size, and
+   content before admission.
+5. The system creates an auditable processing contract and accepts or divides terrain only through
+   an explicitly approved tiling workflow.
+6. The existing frozen terrain pipeline prepares the four representations and 4,096 features.
+7. An approved model runtime may score patches only in an authorized deployment after artifact
+   identity, configuration, and state checks succeed.
+8. The system records bounded `AI_OUTPUT` or `AI_HYPOTHESIS` results using controlled terminology.
+9. Hypotheses enter a permissioned review queue without becoming archaeological determinations.
+10. A qualified human examines selected terrain and supporting evidence.
+11. Human observations and archaeological interpretations remain separately attributed from AI
+    output.
+12. The system produces an auditable report containing scope, provenance, review state, and limits.
+13. Sensitive inputs and derived data follow the project’s approved retention/deletion schedule.
+
+## Capability classification
+
+| Capability | Classification | Minimum requirement or reason |
+| --- | --- | --- |
+| Authentication | MVP REQUIRED | Strong individual identity; no anonymous processing. |
+| Organization and project permissions | MVP REQUIRED | Least privilege with explicit project membership and reviewer roles. |
+| Project workspace | MVP REQUIRED | Stable project purpose, owner, scope, status, and data-policy record. |
+| Terms and authorization attestation | MVP REQUIRED | Record authority to process supplied data and accept handling conditions. |
+| Authorized terrain ingestion | MVP REQUIRED | Controlled local import or private upload; strict type and size allowlist. |
+| Raster validation | MVP REQUIRED | Preserve the Phase 5 canonical contract or use a separately approved preprocessing stage. |
+| Bounded processing | MVP REQUIRED | Explicit quotas, isolation, deterministic job identity, and fail-closed admission. |
+| Job status | MVP REQUIRED | Controlled states and error codes without paths, coordinates, or content leakage. |
+| Approved model runtime | MVP REQUIRED for scored pilot | Disabled unless the private artifact, licence, deployment, and review gates pass. |
+| Review queue | MVP REQUIRED | Permissioned, private, and clearly labelled as machine-generated hypotheses. |
+| Human annotations | MVP REQUIRED | Authenticated author, timestamp, evidence level, rationale, and immutable history. |
+| Evidence-level enforcement | MVP REQUIRED | Machines limited to Levels 1–2; higher transitions require appropriate humans. |
+| Controlled output terminology | MVP REQUIRED | No discovery, probability, clearance, approval, or known-negative claims. |
+| Report generation | MVP REQUIRED | Bounded report with provenance, AI/human separation, limitations, and audit references. |
+| Audit history | MVP REQUIRED | Append-only security and decision events with sensitive-field minimization. |
+| Retention and deletion | MVP REQUIRED | Project policy, expiry, verified deletion, legal-hold exception, and deletion evidence. |
+| Export controls | MVP REQUIRED | Permissioned, reviewed exports; no public candidate-location export. |
+| Multi-tenant managed SaaS | LATER | Requires a separate cross-tenant and public-service approval gate. |
+| Automated reprojection/mosaicking | LATER | Must be an explicit, versioned preprocessing product with equivalence tests. |
+| Integrations with HER/GIS/planning systems | LATER | Require source terms, authorization, field mapping, and leakage review. |
+| Billing and payment | LATER | Commercial operations follow—not establish—workflow safety and demand. |
+| Mobile field application | LATER | Requires location, offline-storage, and field-safety review. |
+| Public API or public upload form | OUT OF SCOPE | Phase 5F is not authorized; anonymous location processing is unsafe. |
+| Public candidate map or feed | OUT OF SCOPE | Conflicts with archaeological sensitivity and evidence boundaries. |
+| Automatic archaeological decision or clearance | OUT OF SCOPE | Software must never make the final archaeological determination. |
+| Automatic retraining or model substitution | OUT OF SCOPE | Would violate the frozen model and evidence boundary. |
+
+## Core screen concepts
+
+- **Projects:** only projects the authenticated user is permitted to access, with purpose, owner,
+  retention state, and review status.
+- **New screening project:** controlled scope and authorization capture followed by bounded terrain
+  ingestion; no public map submission.
+- **Processing:** safe job state, admitted/rejected counts, processing-contract identity, and fixed
+  errors without private paths or coordinates.
+- **Screening results:** private terrain-pattern-similarity hypotheses and aggregate summaries;
+  never automatic “archaeological site” labels.
+- **Review queue:** assigned human review with blinded or score-aware modes defined by protocol,
+  controlled categories, and explicit evidence level.
+- **Evidence record:** immutable separation of machine output, human observation, qualified
+  archaeological interpretation, supporting sources, and any later confirmation.
+- **Report:** permissioned preview/export of bounded findings, provenance, review status, and
+  limitations.
+- **Project settings:** membership, roles, retention/deletion, export permissions, and audit access.
+
+These are information-architecture concepts, not frontend designs or implementation authorization.
+
+## Professional report concept
+
+A report should contain:
+
+1. project identifier, accountable organization, purpose, and authorized scope;
+2. input description, rights attestation, CRS/resolution, and data provenance;
+3. processing contract, software version, model/config identity, and integrity checks;
+4. terrain and representation QA with admitted/rejected aggregate counts;
+5. screening summary using terrain-pattern-similarity terminology;
+6. AI-generated hypotheses with their evidence level and controlled limitations;
+7. human-review state, reviewer identity/role, method, and separately attributed observations;
+8. archaeological interpretation only when supplied and signed by a qualified reviewer;
+9. unresolved limitations, excluded uses, and recommended next professional step;
+10. retention/deletion status and an audit-record reference.
+
+The report must never translate a score into archaeological certainty, certify absence, grant
+approval or clearance, or obscure whether qualified human review occurred.
+
+## Acceptance boundary
+
+An MVP is not credible merely because screens exist. Before use it must pass the Phase 6A decision
+gates, threat/privacy testing, licensing review, model/IP decision, professional workflow review,
+and a separately authorized bounded pilot. Phase 5E completion alone would not authorize it.

docs/product/COMMERCIAL_OPEN_QUESTIONS.md

@@ -0,0 +1,51 @@
+# ArchaeoAI commercial open questions
+
+## Status
+
+This is a prioritized register of unresolved questions, not a set of assumed answers. `BLOCKER`
+means the issue must be resolved for the relevant pilot or deployment; `IMPORTANT` means it should
+shape design and approval; `LATER` means it is intentionally deferred beyond the first bounded
+pilot.
+
+| Category | Severity | Question | Why it matters | Owner/reviewer type needed |
+| --- | --- | --- | --- | --- |
+| Scientific | BLOCKER | What claims and use cases remain defensible when E001 covers one narrow class and bounded geographies? | Product wording and safe decisions cannot exceed evidence. | Research lead, statistician, archaeologist. |
+| Scientific | IMPORTANT | What independent evidence would be required before evaluating another class, terrain source, or geography? | Prevents product pressure from becoming unregistered model expansion. | Research methodologist and archaeologist. |
+| Archaeological | BLOCKER | Which screening decisions may the tool support, and which must remain solely professional? | Defines safe workflow, liability, and evidence transitions. | Qualified archaeological professional and legal adviser. |
+| Archaeological | BLOCKER | What reviewer qualifications and corroboration are required for Levels 3–5? | Prevents software or unqualified review from implying validation. | Professional archaeology body/practitioner. |
+| Archaeological | IMPORTANT | How should sensitive candidate locations be handled across clients, reports, regulators, and archives? | Disclosure may create heritage harm or breach obligations. | Archaeologist, data protection/privacy lead, client. |
+| Product | BLOCKER | Which single professional job is valuable enough for a bounded pilot without implying automated determination? | A credible MVP needs a narrow user outcome. | Product researcher and prospective professional users. |
+| Product | IMPORTANT | What evidence and interface context do reviewers need without anchoring them improperly to scores? | Review design affects bias, burden, and usefulness. | UX researcher, archaeologist, research methodologist. |
+| Product | IMPORTANT | What pilot success criteria measure workflow value, safety, and auditability without reusing scientific tests? | Prevents metrics from overstating product or model performance. | Product owner, research lead, pilot partner. |
+| Security | BLOCKER | Can untrusted raster processing be isolated and resource-bounded under the chosen deployment? | File parsing is a primary attack surface. | Security engineer and platform engineer. |
+| Security | BLOCKER | Can the approved model be loaded without accepting arbitrary pickle risk or exposing the artifact? | Unsafe deserialization can compromise the host and model IP. | ML security engineer and model owner. |
+| Security | IMPORTANT | What identity, authorization, support-access, and incident controls are proportionate for a private pilot? | Sensitive projects require accountable access. | Security architect and deployment operator. |
+| Privacy | BLOCKER | What exact retention/deletion schedule applies to every sensitive data class, backups, and reports? | “Minimum retention” must become enforceable behavior. | Privacy/legal adviser, archaeologist, client records owner. |
+| Privacy | BLOCKER | What lawful basis, notices, contracts, and jurisdiction apply to client terrain and location data? | Processing cannot begin without clear authority and obligations. | Data protection/legal adviser and client. |
+| Privacy | IMPORTANT | Are any aggregated telemetry fields safe and genuinely necessary? | Operational visibility can accidentally disclose location or activity. | Privacy engineer and security reviewer. |
+| Licensing | BLOCKER | Do all source terms permit the intended commercial processing, hosting, derived outputs, and client reporting? | Research permissions do not automatically establish commercial rights. | Licensing/legal specialist and data providers. |
+| Licensing | IMPORTANT | What attribution and redistribution language must appear in reports and exports? | Deliverables must preserve source obligations. | Licensing specialist and report owner. |
+| Model/IP | BLOCKER | Who owns the trained artifact and has authority to use, distribute, host, modify, and support it commercially? | The current private artifact cannot be assumed deployable. | Repository/model owner and IP counsel. |
+| Model/IP | BLOCKER | Is a safer portable model format technically equivalent and legally acceptable? | Hash-bound pickle has code-execution risk; conversion could change outputs. | ML engineer, security engineer, research lead. |
+| Infrastructure | BLOCKER | What local/private packaging and update mechanism preserves reproducibility, signatures, and rollback? | First deployment must be supportable without silent drift. | Platform engineer and security/reproducibility reviewer. |
+| Infrastructure | IMPORTANT | How are append-only audit records and verified deletion implemented, including backups? | Accountability and privacy require both history and controlled erasure. | Platform engineer, security/privacy leads. |
+| Infrastructure | LATER | What tenancy, regional hosting, availability, and disaster-recovery design would SaaS require? | These matter only after a separate public/SaaS decision. | Cloud architect, security/privacy/legal leads. |
+| Business | BLOCKER | Will professional organizations participate in a bounded, paid or unpaid discovery/pilot process? | Technical readiness does not demonstrate demand. | Founder/product researcher and prospective users. |
+| Business | IMPORTANT | Which delivery hypothesis—pilot, per-project, annual licence, private deployment, or enterprise contract—best fits procurement and risk? | Determines operations and product constraints; no price is assumed. | Business lead, procurement stakeholders, legal adviser. |
+| Business | LATER | What pricing, support, insurance, and service-level model is viable? | These require real discovery and cost evidence. | Business/finance/legal leads. |
+| Customer validation | BLOCKER | Do independent professionals understand and accept the terminology, evidence ladder, limitations, and required human work? | Misunderstanding would create unsafe reliance. | External archaeologists and consultancy users. |
+| Customer validation | BLOCKER | Does the workflow improve prioritization or auditability in a real authorized project without displacing required review? | Core value remains unvalidated. | Pilot partner, independent evaluator, product researcher. |
+| Customer validation | IMPORTANT | What objections, integration needs, and adoption barriers recur across different organization types? | Prevents designing from untested assumptions. | Product researcher and diverse prospective users. |
+
+## Highest-priority blockers
+
+The first five questions to resolve are:
+
+1. the defensible professional use and claim boundary for narrow E001 evidence;
+2. commercial source-data and derived-output rights;
+3. model ownership, runtime authority, and safe artifact format;
+4. enforceable security isolation and privacy retention/deletion for authorized inputs;
+5. external professional acceptance of the human-review workflow and evidence ladder.
+
+No blocker is resolved by repository documentation alone. Answers require attributable evidence and
+must be carried into the corresponding commercial decision-gate record.