Explain where each exported value came from
A profile can mix information someone entered with activity the service observed and conclusions the application calculated. Those values do not belong in every kind of export.
Wildo lets you describe their origin in the model, so portability selection follows an explicit rule rather than a guess about field names.
Example — Separate an answer from a score
A person supplies a preference and the application calculates a score. The preference can travel in their portable bundle; the derived score is treated differently, even when both live on the same record.
For engineers
Use portabilityPolicy.defaultProvenance on a resource and .portabilityProvenance(...) on fields that differ. This is independent of personal-data categories and erasure treatments. The actual draft-note configuration supplies a resource-wide default:
Source: draft-notes.resources-config.ts (selected excerpt).
resourceIdentifier: TasksManager_ResourceType.DRAFT_NOTES,
resourceFieldIdentifier: TasksManager_ResourceFieldIdentifier[TasksManager_ResourceType.DRAFT_NOTES],
resourceRelationships: resourcesRelationships,
isSystemResource: false,
isAnonymizable: true,
transpositionPolicy: ResourceTranspositionPolicy.ADD,
// assurance-control: WILDO.PRIVACY.SUBJECT_DATA_EXPORT — authenticated draft notes are subject-owned data and must be available to the fail-closed export sweep.
systemAccessPolicy: { exportSubject: ResourceSystemAccessMode.ALLOWED },
portabilityPolicy: { defaultProvenance: DataPortabilityProvenance.SUBJECT_PROVIDED },
SUBJECT_PROVIDED covers input the person supplied. OBSERVED covers information generated by their use of the service. DERIVED covers the application’s conclusions, scores and assigned classifications. Do not classify all non-typed values as derived: observed usage has its own meaning.
The field declaration overrides the resource default. In the portability selection, provided and observed values are eligible while derived values are excluded and reported. Access selection is broader, subject to the separate non-disclosable-field rules.
An unresolved provenance refuses portability collection instead of silently dropping a field. Choose a default only when it accurately describes the resource, then inspect exceptions such as computed status fields. Your application still decides which request applies and reviews delivery; the declaration is a selection contract, not a determination of legal entitlement.
Override only the fields with a different origin
Illustrative field declaration using the existing decorator; the surrounding resource uses the SUBJECT_PROVIDED default above:
const preferenceFields = z.object({
preference: z.string(),
calculatedScore: z.number()
.portabilityProvenance(DataPortabilityProvenance.DERIVED),
});
The preference inherits the resource default. The calculated score overrides it and is excluded from portability selection, with that selection reported. Access selection remains distinct. This field decision applies only after the relationship has admitted the row; it does not pull unrelated records into the bundle.