#byteor-dataguard

byteor-dataguard is the enterprise runtime surface for schema checks, deterministic redaction, and DataGuard audit output. Use it when the operational contract depends on a file-backed schema registry and a reviewable redaction policy.

#Registry setup

DataGuard execution is explicit. A run is not valid unless the runtime can resolve all of the following:

• --registry-root=/path
• --schema-id=N
• --msg-type=N
• --required-version=N

Those flags tell the runtime which schema family is required, where the registry lives on disk, and what minimum version the incoming envelope must satisfy.

If the required schema is missing, incompatible, or older than expected, DataGuard treats that as a real operator-visible failure rather than a soft warning.

#Rule configuration

Rules are supplied explicitly with repeated --rule= flags.

Supported rule shapes include:

• field:drop
• field:replace_with=VALUE
• field:hash
• field:mask=P:S:C
• field:truncate=N

Payload mode is also explicit:

• --mode=mapkv for map-style postcard payloads,
• --mode=row for row-aligned payloads keyed to schema field order.

The product surface supports check, redact, and fused DataGuard flows, but the operator concern stays the same: the runtime must have a deterministic rule set and a registry state that can be reconstructed later.

#Report interpretation

DataGuard emits a stable kv/v1 report for audit artifacts. The public schema is documented in ../spec/artifact-schemas-v1.md.

Read the report in this order:

1. report.* confirms the artifact family and version.
2. schema.* confirms the registry root and the required schema tuple.
3. policy.* shows whether a redaction policy was active and how it was described.
4. counts.* explains what happened to the data.
5. cost.* appears when cost sampling is enabled.

The high-signal counters are:

• counts.seen, counts.accepted, counts.rejected
• counts.decode_err, counts.codec_mismatch
• counts.schema_missing, counts.schema_incompatible
• counts.out_drop, counts.out_forward_input, counts.out_forward_output
• counts.redact_noop, counts.redact_rewrite
• counts.stage_errors

That split lets operators distinguish schema failures from successful passes, no-op redaction, output rewrites, and stage-level failures without reverse-engineering the runtime internals.

#Operational guidance

• Keep the schema registry under change control; the registry state is part of the runtime contract.
• Treat the DataGuard report as a required deployment or incident artifact, not optional debug output.
• Pair DataGuard changes with replay-friendly evidence: the spec, the rule set, the registry root, and the generated report.
• Use run --sp for controlled proof runs before moving a new rule set into continuous execution.

Use operator-flow.md for the shared incident and replay sequence and ../reference/runtime-cli.md for the full verb surface.