data-cap
    Preparing search index...

    Interface FieldDocs

    Documentation metadata for one field.

    owner, sensitivity, and protections override the capability-level value of the same name for this field specifically -- not every field in a capability is equally sensitive or equally owned. protections and retention are documentation-presence signals only: a generator may say a safeguard/policy is "documented" or "not documented," never that it is adequate, correct, or enforced. purpose/legalBasis/dataResidency/ auditRequired carry the same presence-only discipline -- declared governance facts, never a claim that data-cap has determined they satisfy any law (see specs/decisions/0051-documentdata-metadata-and-governance-fields.md).

    The boundary this interface draws is deliberate: a named property here is reserved for a concept data-cap itself understands, projects, or reports on. Anything else -- organization-specific detail with no data-cap-defined meaning -- belongs in metadata, never as an ad hoc extra property, so this vocabulary stays bounded instead of accreting one-off keys over time.

    Note what is deliberately absent: there is no per-field validate/ validator property, and no helpers.validators combinator library backing one, unlike @maverickcer/env-cap's EnvVarDocs. That is a design choice, not a gap. env-cap validates on a reject-and-throw pipeline, where a failing validator must carry a message explaining the rejection; data-cap has no reject path to write a message for -- invalid processor/operation output resets the field to its declared default via core/schema.ts's checkValueAgainstSchema, keeping fields synchronously readable (AGENTS.md invariant 2) and surfacing the mismatch through DataInfo. See helpers/shape.ts's own module comment for the full reasoning.

    interface FieldDocs {
        auditRequired?: boolean;
        dataResidency?: string | readonly string[];
        deprecated?: boolean;
        deprecatedReason?: string;
        description?: string;
        expiresAt?: string;
        legalBasis?: string;
        metadata?: Readonly<Record<string, unknown>>;
        owner?: string;
        protections?: string;
        purpose?: string;
        removeBy?: string;
        renamedFrom?: string;
        retention?: string;
        sensitivity?: string;
    }
    Index
    auditRequired? dataResidency? deprecated? deprecatedReason? description? expiresAt? legalBasis? metadata? owner? protections? purpose? removeBy? renamedFrom? retention? sensitivity?
    auditRequired?: boolean

    Whether access to this field is documented as requiring an audit trail. Declared only, same presence-only discipline as protections/ retention. Overrides the capability's own auditRequired for this field specifically.

    dataResidency?: string | readonly string[]

    The declared jurisdiction(s) this field's data is permitted/expected to be stored in -- a policy constraint, not an observed fact, not a processing-location claim, not a data-subject-location claim. Overrides the capability's own dataResidency for this field specifically.

    deprecated?: boolean

    Whether this field is documented as deprecated. Presence-only, same discipline as every other declared fact here -- nothing warns at runtime.

    deprecatedReason?: string

    Why this field is deprecated, and what to use instead. Only meaningful alongside deprecated.

    description?: string

    Why this field exists / what it's for.

    expiresAt?: string

    When this field's data (or the credential/source behind it) is declared to stop being valid, as an ISO-8601 date ("2026-12-31"). Declared only: nothing expires anything at runtime, and data-cap never fetches a real expiry from a provider. Build tooling reads it to report what is expiring soon (see the Lifecycle Model) -- a date that has already passed is reported as expired, never acted on.

    legalBasis?: string

    The declared legal basis asserted for processing this field (e.g. "consent", "contract", "legitimate interest"). Records that a basis was declared -- never that data-cap has determined the basis is legally valid. Overrides the capability's own legalBasis for this field specifically.

    metadata?: Readonly<Record<string, unknown>>

    Free-form extension bag for anything data-cap itself has no named concept for -- opaque, never inspected or validated by any code path in this package. Once a concept matters enough for data-cap to reason about, it gets its own named field above; everything else stays here.

    owner?: string

    Overrides the capability's own owner for this field specifically.

    protections?: string

    Overrides the capability's own protections for this field specifically.

    purpose?: string

    The declared reason this field's data is collected/retained. Declared only -- data-cap never verifies the stated purpose matches actual usage. Overrides the capability's own purpose for this field specifically.

    removeBy?: string

    The date by which a deprecated field is intended to be removed, ISO-8601. Field-level only: a removal deadline is about one specific field's own migration, and a capability-wide removeBy would say nothing about which of its fields still need work.

    renamedFrom?: string

    The previous name of this field, when it was renamed. Field-level only, for the same reason as removeBy. Build tooling uses this to correlate an added-field/removed-field pair across two runs into one rename rather than reporting an unrelated addition and deletion -- see ChangeModel's renamedFields. Only ever populated from an authored value, never guessed from name similarity.

    retention?: string

    Documented retention policy for this field -- presence only, never an enforcement claim.

    sensitivity?: string

    Overrides the capability's own sensitivity for this field specifically.

    Settings
    Member Visibility

    On This Page
    Properties