[Feature][Agent] Add a deterministic Flink-native design path to Hudi Architect #19779

Feature Description

PR #19380 introduced the Hudi Architect skill as a workload-driven design advisor that turns user requirements into a Hudi table architecture, an Architecture Decision Record, a configuration bundle, and an executable example.

This proposal extends the existing Hudi Architect skill with a Flink-native design path.

The goal is not to introduce a planner service, a new public API, or an automated deployment system.

The goal is to preserve the existing workload-first design flow while adding the Flink-specific questions, capability constraints, warnings, configuration templates, and validation needed to produce a safe Flink design.

Current gap

The existing Hudi Architect can identify Flink as an execution engine, but it does not yet provide a source-verified Flink design path.

Without a Flink-native path, the skill cannot safely derive:

• Flink SQL DDL and DynamicTable connector options.
• Checkpoint-aligned Hudi commit prerequisites.
• Flink-specific record-key, ordering, partition, and index constraints.
• MOR compaction ownership for a Flink job.
• Flink catalog and metastore synchronization composition.
• Existing-table reconciliation using Flink table options.

As a result, selecting Flink does not yet produce the same level of actionable and source-backed design output as the existing Architect flow.

Version and API baseline

The initial capability baseline is fixed to:

• Apache Hudi 1.2.0.
• Apache Flink 1.20.
• Flink 1.20.1 for build and test fixtures, matching the Hudi 1.2.0 Flink 1.20 build profile.
• Flink SQL using the Hudi DynamicTable connector.
• No XTable integration.

The first milestone generates Flink SQL DDL and Hudi DynamicTable connector options.

DataStream API code generation and HoodieFlinkStreamer generation are outside the first milestone.

They may be added as follow-up capabilities after the Flink SQL path is validated.

The skill may collect source change semantics, but it does not generate a complete Kafka, CDC, JDBC, or other source connector job in the first milestone.

If the user provides another Hudi or Flink version, the skill must not silently apply this capability baseline.

It should explain the mismatch and return REVIEW_REQUIRED unless that version has its own verified capability reference.

Alignment with Hudi Architect

The Flink path should preserve the core behavior of Hudi Architect:

• Ask workload questions instead of asking users to select Hudi internals.
• Deduce low-risk decisions when the result follows directly from workload requirements.
• Explain and confirm durable decisions whose trade-offs depend on the application.
• Apply platform-managed defaults without turning the conversation into a configuration wizard.
• Ask only questions whose answers can change the recommendation.
• Use the existing tier gate and conditionally load deeper questions.
• Expose confirmed facts, assumptions, unsupported combinations, and unresolved risks.
• Produce an ADR and a validated configuration bundle rather than isolated configuration snippets.

Every material recommendation must be traceable to a versioned reference rule or explicitly marked as an assumption or an unverified capability.

The implementation remains knowledge-and-flow based.

Validation scripts may reject invalid inputs or configuration combinations, but they should not become a separate architecture decision engine.

Skill structure

The main SKILL.md should retain the shared tier flow and engine routing.

Shared Hudi decisions such as table type, retention, partitioning principles, cleaning, and table-service posture should remain in the existing common references.

Flink references should contain only Flink-specific questions, capability constraints, option mappings, warnings, and overrides.

Proposed files are:

• references/flink-question-flow.md
• references/flink-decision-overrides.md
• references/flink-config-templates.md
• references/flink-warnings.md
• references/flink-1.20-hudi-1.2.0-capabilities.md

The main skill should link directly to these references and load them only after the Flink path is selected.

This avoids duplicating the complete Hudi decision model and reduces the risk that Spark and Flink rules drift apart.

The existing ADR template should be extended conditionally for Flink.

A separate public Flink planning artifact is not required.

Initial safety gates

Before generating an executable Hudi sink-side example, the skill must establish:

• Whether the target is a new or existing table.
• Whether the requested Hudi and Flink versions match the verified baseline.
• Whether another job or standalone table service can write to the table.
• Whether any consumer requires catalog or metastore visibility.
• Whether a physical table schema is available.
• Whether replayed or backfilled records must be idempotently merged.

These checks must be introduced before the first executable Flink path.

A capability may be implemented incrementally, but an unsupported path must fail closed.

The skill must not:

• Route an existing table through a new-table flow.
• Assume single-writer when the writer model is unknown.
• Omit catalog requirements for external consumers.
• Generate executable DDL without a physical schema.
• Present append-only insert as an idempotent write path.
• Reuse the Hudi 1.2.0 and Flink 1.20 capability baseline for another version without verification.

Schema and record-key requirements

A physical schema is required before the skill can generate executable Flink SQL DDL.

The schema may be provided through:

• Existing Flink SQL DDL.
• SHOW CREATE TABLE output.
• A list of field names and Flink SQL types.
• An existing Hudi table schema.
• Another schema representation that can be mapped to Flink SQL types without guessing.

The skill should validate that:

• Record-key fields exist in the physical schema.
• Ordering fields exist in the physical schema.
• Partition fields exist in the physical schema.
• Index-key fields are compatible with the record key.
• Primary-key syntax and record-key options do not conflict.
• Existing-table schema facts are not silently replaced.

For mutable workloads, record identity and ordering remain non-defaultable design facts.

For append mode, the verified Hudi Flink path may allow the skill to omit an explicit primary key and use auto-generated Hudi record keys.

This must not be applied silently.

When designing an append-only table, the skill should determine whether the data has a stable field, or set of fields, that identifies the same business record across retries and backfills.

If a stable business key exists, the skill should prefer it even when the current workload is append-only.

A stable record key does not by itself make write.operation = insert idempotent.

The Flink insert path may accept duplicate logical records, including duplicates introduced by an independent replay or backfill.

The skill should therefore ask whether the same logical record can appear again because of source replay, retry, or backfill, and whether repeated copies must collapse into one table record.

The decision should be handled as follows:

• If repeated logical records cannot occur, the append-only insert path may continue.
• If repeated logical records are acceptable, the append-only insert path may continue and the duplicate tolerance must be recorded in the ADR.
• If repeated logical records can occur and must collapse into one table record, the workload requires a stable record key and an upsert-capable design.
• If replay behavior is unknown, the result should be REVIEW_REQUIRED.

Until the mutable COW path is implemented, a replay-idempotence requirement should return BLOCKED rather than presenting append-only insert as a deduplicating write path.

If no stable business key exists, the skill may recommend auto-generated Hudi record keys, but it must explain that:

• The design is intended to remain append-only.
• Reprocessing or backfilling the same business record can create another Hudi record with a different generated key.
• Auto-generated keys do not provide business-level deduplication across independent ingestion runs.
• A future transition to upsert semantics requires a stable record key and may require migration or table recreation.
• Using a stable key instead of an auto-generated key improves identity and future upsert compatibility, but it does not make append-only insert idempotent.
• Replay and backfill deduplication must be treated as a separate workload requirement.

The use of auto-generated keys should be recorded as a durable decision in the ADR.

If the user requests executable DDL but does not provide a sufficient schema, the result must be INCOMPLETE.

Schema and record-key information should remain part of the ADR table-design section rather than becoming a separate public contract.

Shared Hudi decisions with Flink constraints

The Flink path should reuse the existing Hudi Architect rules for:

• COW or MOR.
• Record identity.
• Ordering.
• Partitioning.
• Index selection.
• Retention and cleaning.
• Table-service posture.
• Durable table decisions.

Flink-specific references should add only constraints that materially change those shared decisions.

For example:

• A mutable Flink workload requires explicit record identity and ordering.
• Partition-field updates must influence index and update handling.
• A MOR design must identify the compaction owner.
• An independently deployed compactor or clustering job must trigger the multi-writer safety gate.
• Flink state index TTL must not be enabled without a bounded late-update horizon.

The default recommendation for index.state.ttl should remain 0.

A non-zero value should only be recommended when the maximum late-update horizon is known and the TTL exceeds that horizon.

The first version does not need to tune every compaction or clustering threshold.

It must only ensure that required table services have an owner and that the ownership model is compatible with the writer design.

Flink input and output semantics

The skill should distinguish input change semantics from downstream query semantics.

Input requirements include:

• Append-only records.
• Inserts and updates.
• Deletes.
• CDC input whose target is the latest Hudi table state.
• Updates that can move a record between partitions.

Output requirements include:

• Snapshot queries.
• Incremental queries.
• Best-effort changelog queries.
• Hudi CDC queries.

A CDC source is supported when the target contract is the latest Hudi table state.

changelog.enabled should be described as best effort because compaction may merge intermediate changes.

Hudi 1.2.0 also provides a separate cdc.enabled capability.

Full design guidance for Hudi CDC queries, supplemental logging modes, change retention, and downstream replay is outside the initial milestones of this proposal.

If a user requires Hudi CDC query semantics, the skill should return BLOCKED with the reason that the capability is outside the current Skill scope.

It must not claim that Hudi itself lacks CDC support.

Flink runtime prerequisites

The ADR should contain a Flink runtime section that is separate from the Hudi table options.

This section should cover:

• Streaming or bounded execution.
• Whether checkpointing is required.
• The target checkpoint and Hudi commit cadence.
• The relationship between a completed checkpoint and a visible Hudi commit.
• Required Hudi Flink bundle and catalog dependencies.
• Recovery assumptions and post-recovery verification checks.
• Environment-specific deployment inputs.

For a streaming write, the skill must not claim a normal commit cadence unless checkpointing is enabled.

The skill must not claim end-to-end exactly-once solely because the Hudi sink commits on completed checkpoints.

End-to-end guarantees also depend on the source, checkpoint configuration, restart behavior, stable record identity, and the rest of the Flink pipeline.

Checkpoint frequency should be related to the requested commit freshness.

Very short commit intervals should trigger a warning when the expected data volume can create excessive small files or timeline pressure.

These runtime requirements should remain an ADR section rather than becoming a separate public contract.

Freshness model

The ADR should distinguish:

• Commit freshness: when data becomes part of a completed Hudi instant.
• Query freshness: when the selected Hudi query mode can return the data.
• Catalog freshness: when external catalog metadata reflects the committed table state.

These values must not be collapsed into one freshness statement.

For MOR tables, query freshness should also account for whether consumers use snapshot or read-optimized semantics and how compaction is owned.

Catalog synchronization occurs after the Hudi data commit and must not be described as atomic with that commit.

Existing-table evidence

The skill should not assume direct access to object storage, Hive Metastore, AWS Glue, or a running Flink cluster.

For an existing table, the initial version should accept user-provided evidence such as:

• hoodie.properties.
• Flink SQL DDL or SHOW CREATE TABLE output.
• A Hudi CLI timeline summary.
• A list of active writers and standalone table services.
• Existing catalog and synchronization configuration.

The ADR should record where each observed fact came from and when it was observed.

The skill should compare observed table facts, desired application requirements, and the verified capability baseline.

The initial existing-table capability should classify results as:

• Compatible.
• Conflict.
• Unverified.

The skill may identify a safe in-place change or a required migration only when the Hudi 1.2.0 capability references explicitly cover that change.

A complete table-evolution or migration planner is outside the initial scope.

Existing table facts must not be silently replaced by desired values.

A transient pending instant should normally become a deployment-time verification item rather than a permanent architecture decision unless the supplied evidence shows a persistent operational condition.

Catalog and metastore responsibilities

The design should explain two different responsibilities:

• How the Flink application creates and resolves the Hudi table.
• How external query engines discover the table and its partitions.

These responsibilities are conceptually distinct but must be resolved together when generating configuration.

The initial catalog capability should cover:

• Direct Flink SQL table definitions.
• Hudi DFS Catalog.
• Hudi HMS Catalog.
• Hive Metastore synchronization.
• Catalog freshness and post-commit verification.
• AWS Glue compatible integration only after the Flink-specific Hudi 1.2.0 path is verified.

When Hudi HMS Catalog automatically supplies Hive Sync options, the skill must not generate a second conflicting synchronization configuration.

If AWS Glue behavior has not been verified through the Flink-specific code path and fixtures, the result should remain REVIEW_REQUIRED.

A general governance catalog abstraction is outside the initial scope.

Multi-writer scope

The first version must detect multi-writer because assuming a single writer can invalidate an otherwise correct table design.

The initial safety gate should ask whether any of the following can write to the table:

• Another regular ingestion pipeline.
• A backfill or cleanup job.
• A writer using another execution engine.
• A standalone compactor.
• A standalone clustering job.

An in-process asynchronous table service owned and coordinated by the same Flink job is not considered an independent writer.

The initial behavior should be:

• Continue through the supported design path for a confirmed single-writer workload.
• Return REVIEW_REQUIRED when another independent writer exists.
• Return REVIEW_REQUIRED when the user is unsure.
• Withhold a concurrency-sensitive executable configuration until the writer model is resolved.
• Produce a writer inventory and a concise Writer Contract when that capability is implemented.
• Avoid claiming that an OCC, NBCC, lock-provider, or index combination is safe unless it is explicitly verified for Hudi 1.2.0 and Flink 1.20.

The Writer Contract should capture:

• Writer identity.
• Execution engine and version.
• Write operation.
• Table-service ownership.
• Schema evolution owner.
• Existing concurrency mode and lock configuration.
• Combinations that remain unsupported or unverified.

Full automatic multi-writer concurrency planning is outside the initial milestones.

It can be added after Flink-specific multi-writer behavior is confirmed by the community and covered by tests.

Output and status

The Flink path should preserve the existing Hudi Architect output shape:

• One Architecture Decision Record.
• One Flink SQL and Hudi configuration bundle.
• One executable Hudi sink-side example when the design is eligible.
• Warnings, assumptions, validation results, and deployment checks.

The sink-side example may include an INSERT INTO statement that assumes an existing source table.

The example must explicitly identify:

• The required source table.
• The expected source schema.
• The expected source changelog semantics.
• Environment-specific dependencies that are not generated by the skill.

The skill does not claim that the sink-side example is a complete end-to-end Flink pipeline.

The ADR should contain Flink-specific sections for:

• Physical schema and table design.
• Input and output change semantics.
• Flink runtime prerequisites.
• Freshness.
• Catalog visibility.
• Writer assumptions.
• Validation summary.

The final status should be one of:

• INCOMPLETE: required workload facts, schema, or existing-table evidence are missing.
• BLOCKED: the requested combination is explicitly unsupported by the verified baseline or is outside the current Skill scope.
• REVIEW_REQUIRED: an unresolved capability, compatibility, or operational risk requires human confirmation.
• CONFIG_VALIDATED: all load-bearing design values are present and the generated configuration has passed static validation for Hudi 1.2.0 and Flink 1.20.

INCOMPLETE, BLOCKED, and REVIEW_REQUIRED outputs may include an ADR and configuration draft, but they must not present the draft as executable.

CONFIG_VALIDATED means that configuration keys, values, schema references, and supported combinations were statically validated.

It does not mean that storage permissions, JAR deployment, source availability, catalog connectivity, active writers, checkpoint behavior, or live table state were verified.

Environment-specific values may remain deployment inputs, but unresolved load-bearing design values must not appear as placeholders in a CONFIG_VALIDATED configuration.

Validation scope

Validation should cover:

• Flink table options defined in FlinkOptions.
• Flink catalog options defined in CatalogOptions.
• Hudi core hoodie.* properties referenced by generated templates.
• Canonical keys and deprecated aliases.
• Value types and valid enumerations.
• Schema field references.
• Primary-key and record-key consistency.
• Table type, operation, index, concurrency, and table-service combinations.
• Catalog mode and metastore synchronization combinations.

Validation scripts should reject invalid configurations.

They should not select architecture decisions on behalf of the skill.

Representative table DDL fixtures should be validated through HoodieTableFactory.

Representative Hudi catalog DDL fixtures should be validated through HoodieCatalogFactory.

External services such as HMS and Glue should remain deployment checks unless the test environment explicitly provides them.

User-provided DDL, logs, schema, and configuration must be treated as untrusted data rather than agent instructions.

Credentials and tokens must not be requested.

Credential-bearing URIs must be redacted, and generated examples should use secret references.

Non-regression requirement

The Flink extension must not unintentionally change the existing Spark and HoodieStreamer paths.

Existing Spark and HoodieStreamer scenarios should preserve their current questions, decisions, warnings, and generated configurations unless a change is explicitly justified outside this proposal.

At minimum, tests should verify that:

• Spark requests do not load Flink-specific references.
• Flink warnings do not fire for Spark scenarios.
• Flink option validation does not reject valid Spark hoodie.* configurations.
• Existing representative Spark design scenarios retain their expected decisions.

User Experience

The existing Hudi Architect tier gate remains the first interaction.

After the user selects Flink, the skill loads the Flink-specific references and follows a conditional flow.

The first Flink gate establishes:

• New or existing table.
• Other writers.
• Query engines and catalog visibility.
• Availability of a physical schema.
• Replay and backfill idempotence requirements.

The fixed Hudi 1.2.0 and Flink 1.20 baseline should be disclosed.

It does not need to become another question unless the user provides a different version.

The skill then asks only the questions needed by the selected path.

For example:

• Append-only workloads are not asked for an ordering field.
• Append-only workloads are asked whether a stable business key exists before auto-generated keys are recommended.
• Append-only workloads requiring replay idempotence are routed to an upsert-capable design.
• Unpartitioned workloads are not asked about partition movement.
• COW workloads are not asked about compaction ownership.
• MOR workloads must identify a compaction owner.
• Confirmed single-writer workloads do not enter the Writer Contract flow.
• External consumers trigger catalog visibility questions.
• Existing tables trigger evidence collection before new recommendations are produced.
• Executable DDL is withheld until a sufficient physical schema is available.

The skill should:

1. Collect workload requirements, schema, and available evidence.

2. Apply shared Hudi rules and Flink-specific constraints.

3. Explain durable decisions that require confirmation.

4. Surface blocked or unverified combinations.

5. Generate the ADR and configuration draft.

6. Run static validation.

7. Return a final status and deployment checks.

8. Generate an executable Hudi sink-side example only when the result is CONFIG_VALIDATED.

Delivery milestones

Milestone 1 delivers the first safe and executable Flink SQL sink path:

• Hudi 1.2.0.
• Flink 1.20.
• New table.
• Single-writer.
• Append-only.
• COW.
• Streaming checkpoint prerequisites.
• Physical schema and Flink SQL DDL.
• Stable record key or explicitly accepted auto-generated key semantics.
• No replay-idempotence requirement, or explicit acceptance of duplicate records across independent replays and backfills.
• No external catalog requirement.
• Multi-writer, existing-table, unsupported-version, external-catalog, and replay-idempotence fail-closed gates.
• Static DDL and configuration validation.

Milestone 1 validates the complete Flink Skill mechanics, including routing, gated questioning, schema intake, durable key selection, replay-idempotence classification, ADR generation, sink-side SQL generation, static validation, executable eligibility, and Spark non-regression.

It is intentionally not the complete Flink architecture decision surface.

Milestone 2 extends the same design path with:

• Mutable COW workloads.
• MOR and compaction ownership.
• Existing-table comparison.
• Hudi catalog and metastore composition.
• Multi-writer Writer Contract.
• Cross-path validation and Agent evaluations.

The following remain outside these milestones:

• XTable.
• DataStream API code generation.
• HoodieFlinkStreamer generation.
• Complete source connector job generation.
• A public planner service or API.
• Automatic deployment or live infrastructure discovery.
• Full Hudi CDC query design.
• Full automatic multi-writer concurrency planning.
• Flink versions other than 1.20.
• General governance catalog modeling.
• Complete table migration planning.
• Exhaustive compaction, clustering, and performance tuning.

Acceptance criteria

The implementation should satisfy the following invariants:

1. Flink routing uses the Hudi 1.2.0 and Flink 1.20 baseline. Unsupported versions do not silently reuse this baseline.

2. New or existing table, other writers, external consumers, physical schema availability, record-key posture, and replay-idempotence requirements are checked before any executable configuration is generated.

3. The first executable milestone supports Flink SQL through the Hudi DynamicTable connector and does not claim DataStream API, HoodieFlinkStreamer, complete source connector generation, or an end-to-end runnable pipeline.

4. The flow asks only questions that can change the recommendation and continues to use the existing Hudi Architect tier behavior.

5. Executable Flink SQL DDL is generated only when schema fields, types, record identity, ordering, and partition references can be validated.

6. Append-only designs prefer a stable business key when available. Auto-generated keys require an explicit durability warning. The skill does not claim that a stable key makes write.operation = insert idempotent, and replay-idempotence requirements are routed to an upsert-capable design.

7. The ADR separates Hudi table options from Flink runtime prerequisites and does not claim end-to-end exactly-once from sink behavior alone.

8. Mutable workloads require explicit identity and ordering. Partition movement and state TTL participate in correctness decisions.

9. changelog.enabled is described as best effort. Hudi cdc.enabled is recognized as a separate capability and is not incorrectly described as unsupported by Hudi.

10. MOR designs identify a compaction owner. An independently deployed table service triggers the multi-writer safety gate.

11. Existing-table outputs record evidence provenance and observation time. Uncovered evolution and migration decisions remain unverified.

12. Flink catalog registration and external metastore synchronization are explained separately but resolved as one configuration composition. Catalog synchronization is not described as atomic with a data commit.

13. Multi-writer or unknown-writer workloads return REVIEW_REQUIRED and do not receive a concurrency-sensitive executable configuration.

14. Generated table and catalog configurations are validated for schema references, keys, values, and cross-configuration constraints. Secret material is neither requested nor reproduced.

15. Existing Spark and HoodieStreamer paths pass non-regression tests and do not load Flink-specific references.

16. Deterministic CI tests assert rules, configurations, fixtures, warnings, status, and executable eligibility. Agent forward evaluations assert semantic behavior without comparing exact natural-language wording.

Proposed PR breakdown

Each PR should provide a bounded capability and include its own deterministic tests.

1. Flink routing and safety foundation.

   Add Flink routing, the fixed version baseline, new-versus-existing routing, the minimum multi-writer gate, the external-consumer gate, schema-availability detection, record-key posture detection, replay-idempotence detection, output statuses including BLOCKED, lazy-loaded Flink references, secret redaction, and Spark non-regression tests.

   This PR does not claim to generate an executable Flink configuration.

2. First executable Flink SQL sink path.

   Add a new-table, single-writer, append-only COW streaming path using the Hudi DynamicTable connector.

   Include physical schema collection, stable-key preference, auto-generated key warnings, replay-idempotence classification, write.operation = insert, checkpoint prerequisites, commit cadence, Flink SQL DDL, ADR output, an executable Hudi sink-side example, and HoodieTableFactory fixtures.

   The sink-side example must identify its source-table and environment prerequisites and must not be presented as a complete source-to-sink pipeline.

   Add representative fixtures for:

   • Append-only input with a stable record key and no replay-idempotence requirement.
   • Append-only input using auto-generated keys with the required durability warning.
   • Append-only input with a stable key and a replay-idempotence requirement, resulting in BLOCKED until the mutable COW upsert path is available.

   This PR completes Milestone 1.

3. Mutable COW and change semantics.

   Add primary key and ordering requirements, upsert and delete-aware input, partition movement, index selection, state TTL guardrails, CDC input targeting latest state, best-effort changelog guidance, and a scope blocker for Hudi CDC query design.

4. MOR and table-service ownership.

   Add COW-versus-MOR derivation for Flink, minimum compaction ownership, snapshot and read-optimized freshness differences, and standalone table-service detection.

   Do not add detailed compaction tuning.

5. Existing-table comparison.

   Add evidence intake, provenance, observation time, schema and table-property comparison, and compatible, conflict, or unverified results.

   Only emit in-place or migration guidance for changes explicitly covered by the capability references.

6. Flink catalog and metastore composition.

   Add direct Flink SQL, Hudi DFS Catalog, Hudi HMS Catalog, Hive Metastore synchronization, catalog freshness, non-atomic synchronization warnings, bundle requirements, and combined configuration rules.

   Add AWS Glue only after the Flink-specific path is verified; otherwise keep it REVIEW_REQUIRED.

7. Multi-writer Writer Contract.

   Extend the PR1 safety gate with writer inventory, engine and version, operation, table-service ownership, schema evolution ownership, existing concurrency configuration, unsupported combinations, and community-confirmed capability notes.

   Do not add full automatic OCC or NBCC planning in this milestone.

8. Cross-path validation and Agent evaluations.

   Complete HoodieCatalogFactory fixtures, cross-configuration validation, security regression tests, Spark non-regression coverage, and scenario-based Agent forward evaluations.

   Deterministic configuration and fixture tests should run in CI.

   Until the community has a standard Skill evaluation harness, Agent forward evaluations should be attached as PR review evidence and should assert semantic decisions rather than exact response text.

Hudi RFC Requirements

This proposal extends the existing Hudi Architect skill.

It does not change the Hudi table format, timeline semantics, public runtime APIs, or compatibility contracts.

It also does not introduce a new planning service.

Therefore, I do not believe a formal Hudi RFC is required.

If maintainers consider the Architect decision flow or output contract to be a public interface that requires an RFC, I can convert this proposal into the RFC format before implementation.