Skip to content

Leveraging python type hints to validate action/condition function inputs #67

Description

@HugoPerrier

Is your feature request related to a problem? Please describe

I have a large code base relying on Arta as a rule engine.

The input data is currently provided as a complex dict[str, Any] containing many nested structures. As a result, condition and action functions are often polluted with:

  • key existence checks (.get(...))
  • None checks
  • defensive programming around missing or invalid data
  • custom validation logic duplicated across functions

This makes business logic harder to read and maintain, and increases the risk of runtime errors.

Describe the solution you'd like

I would like Arta to support optional input validation based on Python type hints.

For example, if a condition or action function declares a Pydantic model (or any compatible validation model) as its input parameter, Arta could detect the type annotation, validate the incoming data, and pass the validated object to the function.

Example:

class Mail(BaseModel):
    documents: list[Document] = []


def format_document_data(
    mail: Mail,
) -> dict[str, Any]:
    ...

Arta could:

Inspect the function signature.
Detect that the parameter type exposes a validation API (e.g. Pydantic's model_validate).
Validate the incoming data before calling the function.
Pass the validated object to the action or condition.

Functions still typed as dict[str, Any] would continue to work unchanged.

This would provide a gradual migration path from untyped dictionaries to validated domain models while preserving backward compatibility.

Describe alternatives you've considered

I could transform the input dictionary into a dict-compatible validated object following the Business Objects approach described here:

https://maif.github.io/arta/business_objects/

However, this would require significant changes of my existing code base, whereas function-level validation based on type hints would allow incremental adoption.

Expected improvements

Potential benefits:

  • Better IDE autocompletion and type safety
  • Reduced boilerplate (.get() and None checks)
  • Early detection of invalid input data
  • Easier maintenance of complex workflows
  • Backward compatibility with existing dictionary-based implementations

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions