Design a YAML-Configured Point-Cloud Transformation Pipeline

Design a configurable point-cloud preprocessing pipeline. It reads a YAML configuration describing a sequence of transformations, validates that configuration, builds the data flow, and applies the transformations to point-cloud data. ### Requirements and Constraints Cover the YAML schema, interface abstractions, configuration validation, dataflow model, and execution. No particular transformation library, point-cloud format, or mandatory transformation list is supplied. Use clearly labeled examples if needed, and keep the design extensible without allowing arbitrary configuration text to become executable code. ### Part 1 — Define the Configuration and Interfaces Explain how YAML identifies transformations and their parameters, and how implementations expose a common interface. #### What This Part Should Cover - A versioned configuration shape and explicit transformation identifiers. - Parameter schemas, transformation registration, and input/output data contracts. - The treatment of coordinate frames, units, point attributes, and transformations that change point count. ### Part 2 — Validate and Build the Data Flow Validate the configuration before processing expensive data and construct its execution order. #### What This Part Should Cover - Syntax, schema, parameter, and semantic validation with useful error locations. - The distinction between an ordered sequence and a graph with explicit dependencies. - Compatibility between neighboring transformations and rejection of invalid references or cycles if a graph is supported. ### Part 3 — Apply and Observe Transformations Explain how the pipeline runs and how failures or unexpected outputs are handled. #### What This Part Should Cover - Execution order, mutation or ownership rules, and propagation of point-cloud metadata. - Handling of empty clouds, invalid numeric values, and transform failures according to explicit contracts. - Reproducibility, stage-level observability, and tests that verify composition rather than only isolated transforms. ```hint A syntactically valid configuration can still describe an invalid pipeline A parameter can have the correct type while requesting an impossible transform, or one stage can produce attributes the next stage cannot use. Validate meaning as well as YAML structure. ``` ### What a Strong Answer Covers The design connects a clear configuration schema to registered implementations and a validated dataflow plan. It preserves point-cloud semantics, makes ordering and mutation explicit, reports actionable errors, and can add transformations without rewriting the pipeline runner. ### Follow-up Questions 1. What changes if a transformation removes points while another stage expects per-point attributes aligned to the original cloud? 2. How would you prevent a misspelled parameter from silently taking a default value? 3. When would a simple ordered list be preferable to a DAG, and what additional validation does a DAG require?