# LE0N × Pure O1 — Technical & Commercial Appendix (v6 SEND-SAFE)

## 1. Partner model
The proposed default is white-label subcontracting. PureO1 owns the end-client relationship, controls the final selling price and invoices the end client. LE0N receives an agreed partner delivery fee for a clearly isolated scope. The commercial spread stays with PureO1 before PureO1's own internal costs. Exact pricing is agreed per pilot/task; the calculator in the demo is illustrative only and is not an offer.

## 2. Client protection / operating rule
- LE0N operates as a white-label subcontractor inside the agreed delivery process.
- End-client commercial ownership remains with PureO1.
- Scope and LE0N partner quote are agreed before implementation.
- Any direct end-client communication, if required, should follow the process agreed with PureO1.

## 3. Revenue paths for PureO1
1. Delivery spread: PureO1 sets the end-client price above the agreed LE0N delivery fee.
2. Existing-client upsell: small modules, integrations and automations can become separately billable extensions.
3. Backlog monetization: isolated tasks that do not justify main-sprint capacity can still be sold and routed to LE0N.
4. Optional recurring layer: maintenance/enhancement packages can be structured separately if both parties agree commercial and support terms.

## 4. What is real in this proof
- `api.php` is a real deterministic HTTP endpoint accepting JSON and returning a structured qualification result.
- `GET api.php?health=1` exposes health/version.
- `POST api.php` validates the request and returns a versioned handoff shape.
- `openapi.json` documents the endpoint contract.
- The frontend distinguishes LIVE PHP from static fallback.

## 5. What is intentionally not production yet
- No production authentication/authorization.
- No persistent database writes.
- No rate limiting.
- No external LLM call/evaluation pipeline.
- No production observability or secrets management.

## 6. Suggested production boundary
`Partner UI/source system -> validation -> deterministic business core -> optional provider-agnostic LLM adapter -> versioned REST/webhook output`

## 7. Security baseline for a real pilot
1. HTTPS only.
2. Authentication agreed with the partner.
3. Explicit PII scope and retention policy.
4. Payload/schema validation and size limits.
5. Structured logging without leaking secrets/sensitive data.
6. Rate limiting/abuse controls where public.
7. Secrets in environment/secret manager, never frontend code.

## 8. Error model
- `400 invalid_json` — malformed/oversized JSON.
- `422 validation_error` — valid request but missing/too-short brief.
- `405 method_not_allowed` — unsupported method.
- `200 qualified` — accepted deterministic qualification response.

## 9. Pilot deliverables
- Isolated repository/module boundary with agreed ownership.
- OpenAPI contract and example payloads.
- Acceptance criteria before implementation.
- README/environment configuration.
- Integration tests for critical path.
- Deployment/rollback notes.
- Optional Docker/CI according to partner environment.

## 10. Suggested stack
The proof uses plain HTML/CSS/JS + PHP for zero-friction shared-hosting deployment. A production module should follow the PureO1 target environment; typical options can include TypeScript/Node.js or PHP/Laravel, REST/OpenAPI, PostgreSQL, Docker and CI.