Product · Policy and dictionary

Your rules, your dictionary, your key

The customer writes the rules and holds the key; Zindagi never sees either.

The policy

The policy is the customer’s

in development

The policy is the customer's: a YAML document, versioned, hashed and signed by the customer's policy author, stored per tenant and never exported in plaintext outside the tenant. Zindagi never sees the policy or the key. Its sections: the dictionary; the treatment of each class; the preserve list; member actions by path pattern — rewrite, drop, pass, or redact a section; the output pool; attestation options; and review thresholds.

SPECIMEN — SYNTHETIC VALUES · a policy excerpt, as the policy author writes it
# policy: example-release        signed by the customer's policy author
dictionary:
  - cidr:     203.0.113.0/24 -> 100.64.7.0/24   # prefix length preserved
  - hostname: EXAMPLE-CORE   -> SITE-07         # label by label
  - keyword:  ops-north      -> keyword-a
classes:
  addresses:  prefix-preserving, key-derived   # pool 100.64.0.0/10
  hostnames:  keyed token per label
  secrets:    drop and mark                    # never tokenised
preserve:
  - loopback, multicast, broadcast, documentation ranges,
    well-known resolvers
members:
  - "EOs/":          rewrite         # object dumps
  - "core*":         drop
  - "support/db/":   drop, declare   # database export
review:
  threshold: ambiguous hits to the queue;
             nothing silently masked or kept
SPECIMEN — SYNTHETIC VALUES · dictionary rules from a policy excerpt
  1. subnet

    203.0.113.0/24 becomes 10.1.1.0/24

    an explicit pin — always wins; prefix length preserved

  2. hostname

    EXAMPLE-CORE becomes SITE-07

    a site name pinned to a site token

  3. keyword

    building-c becomes <dropped>

    a location word, dropped and marked

  4. preserve

    198.51.100.1 becomes 198.51.100.1

    a value deliberately left as it is (the documentation range, a resolver, a version string)

Explicit dictionary rules always win

Explicit dictionary rules always win over the algorithmic transforms, and they are typed: a subnet to a subnet, a host to a host, a hostname label to a label, a keyword to a keyword, a pattern with named groups to a typed token. Host pins derive from the prefix rule, so every host inside a pinned subnet lands consistently inside the target subnet; prefix length is preserved, and a rule whose two sides differ in length is rejected when the policy is compiled. Everything the dictionary does not pin is rewritten by key-derived, prefix-preserving transforms — for addresses, the Crypto-PAn scheme, implemented from the paper, into the configured output pool (by default 100.64.0.0/10, the shared address space of RFC 6598) — so two addresses that shared a prefix before rewriting share one after, and the TAC can still reason about the topology. Hostnames are tokenised label by label; identifiers and people become typed tokens; secrets and certificate bodies are dropped.

The preserve list, and the test before signing

The preserve list ships with defaults — loopback, unspecified, multicast and broadcast addresses, the documentation ranges, well-known public resolvers (selectable), object-identifier roots and the product version strings the profile declares — and the policy may extend or narrow it. Overlapping rules and pool collisions are rejected at save with a clear message. Before a policy is signed it can be tested against the tenant's canary corpus — synthetic bundles with planted sensitive values and planted look-alikes — and the test reports recall on the planted values and the over-mask rate on the look-alikes. No universal policy is ever shipped as safe for every customer; every policy is the customer's and is signed by them.

The transform

Prefix-preserving, key-derived

in development

Everything a dictionary rule does not pin is rewritten by a prefix-preserving, key-derived transform: two addresses that share a prefix before rewriting share one after, so subnet structure survives and the TAC can still reason about the topology. Replacements are drawn into a declared output pool — by default the shared address space 100.64.0.0/10 of RFC 6598 — so a recipient knows that anything in it is a replacement.

The policy is a versioned, signed YAML document owned by the customer. Explicit dictionary pins — this subnet to that subnet, this site name to SITE-07 — always win; prefix length is preserved, and a rule whose two sides differ in length is rejected when the policy is compiled. Everything else is rewritten by key-derived, prefix-preserving transforms, so subnet structure survives and the TAC can still reason about the topology. The same key gives the same replacement across bundles and across time, so a case thread that spans several uploads stays coherent. Secrets are never tokenised — credentials, keys and private-key bodies are dropped and marked.

Policy inheritance

planned

Policy inheritance — tenant default, bundle-family overrides, job overrides, all recorded — is full product.

How it works, in depth → The attestation, in full →

Status, and the next step

LogVeil is in development. An early-access programme opens after our first field trial.

Early access is a free, guided proof-of-concept on your own bundles inside your own network: you choose the bundles, you write the policy with our help, and you keep the key; we hand over the offline kit, run the first jobs with your engineers, and leave you with the attestations.

Request early access