faker

faker replaces each entity with a plausible synthetic value of the same type. Unlike constant or type_numbered, the output keeps the shape of valid-looking data, which is useful when downstream code expects names, emails, phone numbers, or other formatted values.

Parameters

Parameter	Type	Default	Description
`faker_type`	STRING	inferred from entity type	Override the faker method (e.g., `"name"`, `"email"`, `"phone_number"`).
`locale`	STRING	`"en_US"`	Operator locale (e.g., `"en_GB"`, `"ja_JP"`). Affects name styles, phone formats, addresses.
`seed`	INT	random	Deterministic seed for reproducible replacements with the same input, configuration, and processing order.

Example — default faker

SELECT app_public.mask(
  'Patient Jane Morrison, SSN 918-23-4567, phone 555-0100',
  OBJECT_CONSTRUCT(
    'entity_config', OBJECT_CONSTRUCT(
      'PERSON', OBJECT_CONSTRUCT('operator', 'faker'),
      'US_SSN', OBJECT_CONSTRUCT('operator', 'faker'),
      'PHONE_NUMBER', OBJECT_CONSTRUCT('operator', 'faker')
    )
  )
);
-- Patient Michael Garcia, SSN 412-68-9753, phone 555-0142

Example — seeded for reproducibility

Set a seed to make replacements reproducible for the same input and configuration. This is useful for testing and stable demo data.

SELECT app_public.mask(
  'Contact John Smith at 555-0100',
  OBJECT_CONSTRUCT(
    'entity_config', OBJECT_CONSTRUCT(
      'PERSON', OBJECT_CONSTRUCT(
        'operator', 'faker',
        'operator_params', OBJECT_CONSTRUCT('seed', 42)
      )
    )
  )
);

When to use

Test data generation: create valid-looking de-identified datasets from sensitive source data.
Demos and training: share dataset shapes without exposing source values.
QA: run integration tests against formatted synthetic emails, phones, SSNs.

Notes

faker does not preserve a semantic relationship between the original and synthetic value. For example, “John Smith” might become “Patricia Johnson”.
Without a seed, outputs can change across calls. With a seed, replacements are reproducible for the same input, configuration, and processing order.
Consistency is per row; uniqueness is per request. The same value within one row gets one synthetic replacement. The same value in two different rows is handled independently, so it may receive different replacements unless you use identity features such as identity resolution.
Two different identity values in one request do not share the same synthetic replacement. When you supply ledger_seed, Agent Mask preserves that separation across requests. Exception: the bounded AGE and AGE_OVER_89 generators can repeat because ages are not identity keys.
Synthetic values are valid-looking, not verified fictional values. They can resemble or match real-world people, addresses, phone numbers, emails, or identifiers. Do not use faker output in public communications.