# DISCOVER personalization inputs

This directory contains safe, synthetic examples for the Healthcare Research and Innovation Leader edition of DISCOVER Mission Control. They demonstrate file shape and review behavior; they do not represent a real person, employer, study, participant population, authority, approval, consent, product, result or scientific finding.

## Accepted inputs

The build must accept only the two closed, derived adapters copied into `personalization/input-schemas/` during package assembly:

- `discover-packet-input.schema.json` with `schema=NAIO-DISCOVER-PACKET-ADAPTER-1` and `packet_schema_version=1.0-draft`;
- `soul-profile-input.schema.json` with `schema=NAIO-SOUL-PROFILE-ADAPTER-1` and `profile_schema_version=1.0-draft`.

The examples here must validate against those exact baseline schemas. `schemas/DISCOVER-Mission-Profile.schema.json` is the separate approved-output contract. It is not a substitute input format.

Raw Discover interviews, raw Soul Quiz answers, transcripts, scoring traces and free-form source packets are prohibited. Do not import PHI, participant or prospective-participant information, employee/personnel information, confidential protocol or study material, sponsor/grant/contract information, unpublished findings, identifiable community feedback, proprietary IP, security details, credentials, keys or tokens. Use public, synthetic or explicitly approved metadata only.

## Import and approval sequence

1. Select one derived adapter file locally. Do not auto-scan the device, Hermes memory or cloud storage.
2. Enforce size, nesting, unsafe-key, direct-identifier, credential and prohibited-content checks before parsing.
3. Validate the exact schema/version and reject all additional properties.
4. Create a transient normalized proposal. Do not persist the raw adapter or raw Soul material.
5. Map fields under `implementation/DISCOVER-Personalization-Mapping-Crosswalk.md` and attach field-level provenance.
6. Present conflicts, uncertainty, setting/workspace candidates and authority questions to the user.
7. Require the user to select exactly one Primary workspace. Additional workspaces may be Supporting, Emerging or Contextual.
8. Let the user edit, approve or reject each proposal group. Neither a role label nor a Soul result verifies employment, expertise, authority, IRB/HRO status, consent or permission.
9. Validate the proposed output against the Mission Profile schema and the semantic rules before one atomic save.
10. Keep every recommended workflow, power, template, agent, tool, connector and memory category inactive. Recommendation is not adoption, permission, activation or execution.

If neither adapter is supplied, first run asks only the minimum fields needed to create a proposed profile: display name, mission, values, current priorities, strengths/growth areas, global goals, workspace candidates and Primary choice, situation, working/presentation/accessibility preferences, AI boundaries, memory choice, governance edition/data boundary and authority status. `Unknown` is an acceptable authority answer and must block dependent action.

## Output behavior

The derived Mission Profile is user-editable and versioned. Every user-visible approval group has a `field_provenance` record with source type/reference, source pointer, mapping rule, derivation, uncertainty, approval state and times. Keep references bounded and nonsensitive; a reference is not permission to retain source content.

The profile must preserve global goals separately from each workspace's priorities and goals. Never copy one workspace's goals, authority or data boundary into another. A private whole-life workspace remains owner-private and must not become an institutional, employment or research record.

## Catalog identity rule

The validated baseline adapters recommend `DSC-WF-01` through `DSC-WF-24`. In the canonical research-and-innovation source pack, each is an **inventory ID** attached to one current runnable workflow `WF-01` through `WF-24`. Resolve the relation through the installed versioned catalog record, including its power and template IDs. Do not derive the current ID by stripping `DSC-`, by matching only the number, or by relying on display text.

For example, a source recommendation `DSC-WF-16` is retained in `source_recommendation_ids`. Only when the pinned catalog explicitly resolves that record to `WF-16`, `PWR-16` and `TPL-17` may those current IDs be proposed. A missing, duplicate, renamed or version-mismatched relation is blocked and shown as unresolved. Even a valid resolution leaves `activation_state=recommendations_only_inactive`.

## Synthetic fixtures

- `DISCOVER-Discover-Packet.synthetic.example.json` — valid derived Discover adapter;
- `DISCOVER-Soul-Profile.synthetic.example.json` — valid derived Soul adapter with exactly one Primary role candidate;
- `DISCOVER-Mission-Profile.synthetic.example.json` — proposed derived profile with three isolated workspaces and exactly one Primary.

Synthetic/demo content is visibly labeled and excluded from badge evidence, operational analytics, research records, institutional reports and outcome claims. Deleting the Mission Profile deletes its approved derived settings and provenance without pretending to delete data in external systems.
