# Self-Service Pilot Flow

Use this flow when a customer runs the current free Nexmoot self-service pilot without founder, operator, partner, reseller, consultant, or third-party participation in the customer process.

## Rule

The customer configures the required inputs and receives the result from Nexmoot. No person from Nexmoot, the founder, a partner, or a delegated operator participates in scoping, review, handoff, or delivery.

The primary self-service UI path is:

1. Customer opens `/` and immediately sees that Nexmoot delivers one complete evidence package for one AI agent: readiness decision, evidence files, signed Trust Passport, policy artifacts, and delivery ZIP.
2. Customer selects `Start self-service assessment` and signs in through `/login`.
3. Customer lands in `/app` or goes directly to `/app/new-assessment`.
4. Customer confirms the `Free for now` Complete Agent Readiness Packet. Payment collection and paid tiers are not implemented in this stage; the single option defines the delivery expectation.
5. Customer supplies explicit source input and Trust Passport audience.
6. Nexmoot calls `POST /api/self-service/assessment` from the customer-facing wizard.
7. Nexmoot creates the assessment run.
8. Nexmoot records an automated self-service reviewer decision.
9. Nexmoot issues the Trust Passport or evidence-backed denial result.
10. Nexmoot marks the delivery packet ready.
11. Customer opens `/app/results/{runId}` and downloads Evidence Packet, Trust Passport, SARIF, OPA bundle, and delivery ZIP.
12. Customer maps the recommendations into customer-owned IAM, CI, OPA, SIEM, reverse proxy, or runtime gateway controls.

The public homepage must keep the current positioning explicit: services are free for now, there is one complete option, and the customer can see `What you receive`, `How it works`, and `Decision outcomes` before signing in.

The API automation path is:

1. Customer obtains access to a configured Nexmoot self-hosted instance.
2. Customer completes local owner setup.
3. Customer configures license, backup key, data directory, and production runtime settings.
4. Customer submits assessment input through `POST /api/self-service/assessment`.
5. Nexmoot creates the assessment run.
6. Nexmoot records an automated self-service reviewer decision.
7. Nexmoot issues the Trust Passport or evidence-backed denial result.
8. Nexmoot marks the delivery packet ready.
9. Customer downloads Evidence Packet, Trust Passport, SARIF, OPA bundle, and delivery ZIP.
10. Customer maps the recommendations into customer-owned IAM, CI, OPA, SIEM, reverse proxy, or runtime gateway controls.

## API Path

The UI path is preferred for self-service customers. Use the API directly only for customer-owned automation or smoke checks.

Use:

```powershell
Invoke-RestMethod -Method Post "http://127.0.0.1:3000/api/self-service/assessment" `
  -ContentType "application/json" `
  -Body (@{
    repo_url = "https://github.com/customer/repo"
    branch = "main"
    pull_request = 123
    audience = "customer-workspace"
    customer_id = "customer-workspace"
    operator_id = "customer-self-service"
  } | ConvertTo-Json -Depth 8)
```

The endpoint returns:

- `mode: "self_service"`;
- `human_intervention_required: false`;
- delivered assessment run;
- Evidence Packet;
- Trust Passport;
- artifact download links for Evidence Packet, JSONL evidence, Trust Passport JSON, Trust Passport JWS, SARIF, OPA bundle, and delivery ZIP.

The request must still run inside the configured self-hosted authorization boundary. The caller needs permission to create the run, issue the Trust Passport path, and mark delivery ready. Self-service means no Nexmoot human, delegated operator, partner, reseller, consultant, or third party participates in customer scoping, review, handoff, or delivery; it does not bypass local auth, license, audit, or customer secret-custody controls.

## Supported Inputs

The self-service endpoint reuses the same explicit source contract as `POST /api/assessment-runs`:

- `local_path` with optional `test_command`;
- `repo_url` with optional `branch`, `pull_request`, and `github_fixture`;
- `passport_class: "mcp"` with `mcp_server`;
- `passport_class: "browser"` with `browser_agent`;
- `passport_class: "memory"` with `memory_system`.

Empty source requests are rejected. Production reads do not seed demo runs or demo customers.

## Automatic Decision Boundary

The automated decision is deterministic and based on submitted assessment input and Nexmoot inspection evidence. It is marked with reviewer id `automated-self-service`.

This is not a human audit opinion. It is an evidence-backed machine-generated readiness decision that the customer can use in customer-owned enforcement systems.

## Customer Responsibilities

The customer owns:

- truthful and complete assessment input;
- IAM and repository access;
- CI and branch protection;
- OPA or policy-engine deployment;
- SIEM retention and alerting;
- reverse proxy and runtime gateway controls;
- backup storage and host secret custody;
- legal, compliance, procurement, and internal policy decisions.

## Non-Claims

Nexmoot does not claim:

- unrestricted agent safety;
- vulnerability-free generated code;
- external audit certification;
- human review;
- third-party review;
- SOC 2, ISO 27001, PCI, HIPAA, FedRAMP, GDPR, or other external certification;
- replacement of customer enforcement systems.

## Market Gate

The product is market-ready for the self-service motion when:

- production evidence is refreshed for the selected final customer-facing commit;
- `/`, `/login`, `/app`, `/app/new-assessment`, `/app/results/{runId}`, and `/app/operations` render the expected public, authenticated, delivery, and operations surfaces;
- `POST /api/self-service/assessment` passes release tests;
- the customer can complete owner setup and submit assessment input without Nexmoot human participation;
- generated artifacts are downloadable from the returned links;
- docs state that customer enforcement remains customer-owned.