Model Development Guide¶
This guide documents the modeling conventions of flync.core and flync.model — what
makes a new class, field, or validator feel native to FLYNC. Nearly every rule here is enforced
somewhere — by mypy with the pydantic plugin, by scripts/ci/check_lazy_typing.py, by the
model docstring check, by the error catalog tooling, or by SonarQube — and each page names the
gate that backs it, so you can tell a checked rule from a convention.
Anatomy of a model: base class, fields, docstrings, private attributes, typing rules.
How fields map to the repository layout, and how variant types are discriminated.
Choosing a validator, raising cataloged errors, pinning them in tests.
Rules at a glance¶
Every model extends
FLYNCBaseModel—extra="forbid"and the dump behavior come with it.Every field is documented in the class docstring’s NumPy
Parameterssection, with a:class:cross-reference for its type and the default stated — as a", optional"suffix or in the description.Literaltags anddefault_factorycollections are exempt.Variant types carry a
Literaltag field and are referenced withField(discriminator=...)— never branched on withif/elseover dict keys.Private attributes are written
_name: T | None = None;PrivateAttr(default=...)is no longer used anywhere insrc/.New code uses PEP 604 unions (
A | B,X | None) — a convention SonarQube checks, not something the tree already satisfies everywhere. Annotations are not quoted unless the name is genuinely unbound at that point, whichcheck_lazy_typing.pydoes gate.@model_validator(mode="after")methods returntyping.Self.Validation failures raise
err_minor/err_major/err_fatalfromflync.core.utils.exceptionswith aCategoryand a globally uniqueerror_number; warnings usewarnand are not raised. New ids come fromflync errors get-next-number, the catalog is brought in step withflync errors sync.Negative tests pin the exact id with
assert_single_errorandassert_single_warningfromtests/error_assertions.py.
Further reading in the SDK reference: Field Annotations, Error Propagation.