#Stage Identity

This page documents the public stage-identity convention used across the ByteOr operator story.

#Stable Product Keys

Product stages use stable, human-readable keys:

• dataguard_check
• dataguard_redact
• dataguard_fused

Configuration for these stages belongs in files, environment variables, bundle config, or runtime flags — not in the stage key itself.

#Parameterized Action Keys

Action-like stages embed their target in the key because the target is the stage identity:

• http_post:<url>
• exec:<program>|<arg>|...

These keys are resolved through the enterprise action layer rather than through configuration hidden inside the spec.

#Design Rationale

• Stable keys keep specs reviewable and cache-friendly
• Parameterized keys are appropriate for adapter-like actions where the target is the point
• Complex configuration should stay in runtime config, stage config, or deployment bundles

#Where Mutable Configuration Belongs

Stage identity should tell you what kind of thing the pipeline is invoking. It should not hide deployment-specific values that belong to config bundles, environment variables, registry roots, or runtime flags. That separation is what keeps review, caching, replay, and approval scope readable.

#Related Canonical Surfaces

If a stage needs more than a small target identity, prefer a config file path, registry root, or bundle-supplied parameter source over encoding configuration in the stage key.

#Adapter Catalog

Transport-facing adapters are separate from stage identity. Current adapter families:

Adapters are deployment wiring, not core pipeline semantics. Pair adapter configuration with the right product binary: EdgePlane for transport loops, ActionGraph for action stages, DataGuard for protected data flows.