Model Validation and Change Protection

The model graph monitors every change you make: property renames, type changes, key role modifications (PK, FK, NK), required and unique flag changes, constraint modifications (min/max length, patterns, enums), relationship cardinality changes, edge deletions, schema drift, and protocol-level breaking changes. Comprehensive validation rules, schema drift detectors, protocol compatibility checks, and full impact analysis mean that no architectural change goes undetected.

March 5, 2026

Software developers would never ship code without a compiler. The compiler watches every line, catches type mismatches, flags missing references, and refuses to build when something is broken. Architecture has never had this. A data model with a foreign key pointing to a deleted entity, a property rename that silently breaks three API contracts, a cardinality change that invalidates downstream join paths - these errors are invisible in traditional tools. They surface weeks or months later as production incidents.

NeoArc Studio treats your data model the way a compiler treats source code. Every change you make is monitored. Every property rename, type change, key role modification, constraint update, relationship edit, and edge deletion is validated against the entire downstream dependency graph. The system does not just check the model in isolation - it traces the impact of every change through schemas, API contracts, search indexes, views, governance references, and documentation. No change, no matter how small, goes undetected.

What Gets Monitored

The validation system watches every aspect of the model. Here is what it tracks across entities, properties, relationships, and downstream artefacts.

Property Renames

When you rename a property, the system traces the impact through every schema field, API contract, search index, Data View, and governance block that references it. Duplicate property names within an entity are caught immediately.

Type Changes

Changing a property type triggers validation against all FK references (type mismatch detection), schema field mappings, database profile resolution, search projection types, and API serialisation output.

Key Role Changes

Modifications to primary key (PK), foreign key (FK), natural key (NK), surrogate key (SK), and composite key (CK) roles are validated. Multiple PKs, unresolved FKs, circular FK chains, and FK type mismatches are all caught.

Required and Unique Flags

Adding or removing required and unique constraints is tracked. A required property without a type is flagged. Changes to required status impact API contract compatibility.

Constraint Changes

Modifications to minLength, maxLength, pattern validations, minValue, maxValue, and enum value lists are detected. These affect parameterised database type templates, API validation rules, and schema definitions.

Relationship Changes

Edge cardinality changes (1:1, 1:N, N:M), label renames, direction reversals, and edge deletions all trigger impact analysis. Cardinality changes are flagged as dangerous because they can invalidate FK constraints and join paths.

Model Validation Rules

The validation engine runs a comprehensive set of rules against your model, classified by severity (error, warning, info) and by category (structural, semantic, domain). Structural rules always apply. Semantic rules apply in conceptual and graph-db modes. Domain rules apply only in graph-db mode.

Edge Change Impact Analysis

Relationships between entities are not just visual decorations. They represent real constraints: foreign keys, join paths, cardinality rules, and API contract structures. Changing a relationship can break downstream schemas, invalidate database constraints, and silently corrupt data flows. NeoArc treats every relationship change as a potential breaking change and presents an impact confirmation before it is applied.

Change Type	Risk Level	What It Can Break
Cardinality change (e.g., 1:N to N:M)	Dangerous	May invalidate FK constraints, change join paths in derived schemas, require junction table creation, and break API response structures that assumed single-valued relationships
Label rename	Medium	Updates the relationship name in all views, derived schemas, and published documentation. May affect API field names if the relationship label is used in schema generation.
Direction reversal	Dangerous	Changes the semantic meaning of the relationship. May reverse FK ownership, affect derived schemas that depend on the source-to-target direction, and break navigation patterns in graph views.
Edge deletion	Dangerous	Removes the relationship entirely. Any schema, view, or documentation that references this relationship becomes invalid. The Intent Graph traces all dependents before deletion is allowed.

Schema Drift Detection

Schemas that reference model entities can drift from the model over time. The schema drift detection service continuously compares each schema's fields against the source model entity to identify discrepancies.

Drift Type	Severity	What It Detects
property_removed	Error	A model property that was mapped to a schema field has been removed from the entity. The schema references a property that no longer exists.
type_changed	Error	A model property's abstract type has changed since the schema field was created. The schema field type no longer matches its source.
api_excluded	Warning	A model property that is mapped to a schema field has been excluded from the API projection. The field should be in the schema but the model says it should not be exposed.
new_property_available	Info	A new API-included property exists on the model entity but has not been added to the schema. The schema may be missing a field.
field_name_changed	Info	The model property's API field name override has changed since the schema field was created. The schema field name may be outdated.

Protocol Breaking Change Detection

For gRPC services that use Protocol Buffer message definitions derived from the model, the proto breaking change detector validates wire-format compatibility when model properties change.

Change	Severity	Wire Compatibility Impact
Field removed (without reservation)	Error	Existing clients sending data for this field will have it silently ignored. If the field number is reused, data corruption occurs.
Field number changed	Error	Breaks wire format. Existing serialised data will be decoded incorrectly. Existing clients will send data to the wrong field.
Field type changed	Error	Type encoding changes at the wire level. Existing data cannot be decoded with the new type definition.
Field cardinality changed (singular to repeated)	Error	Wire encoding differs between singular and repeated fields. Existing data will be misinterpreted.
Oneof field moved in/out of group	Error	Changes the wire-level semantics of mutually exclusive fields. Existing clients may send invalid combinations.
Enum value removed	Error	Existing data using the removed value will be decoded as unknown. Behaviour depends on language runtime.
Enum value number changed	Error	Existing serialised enum values will decode to the wrong name.
Reserved field conflict	Error	A field uses a number or name that has been reserved. This will cause compilation failures in proto tooling.
Field removed (with reservation)	Warning	Field is properly reserved, preventing accidental reuse. Still a potentially breaking change for active consumers.
Field added	Info	New fields are backward compatible. Existing clients will ignore unknown fields.
Enum value added	Info	New enum values are backward compatible. Existing clients may not recognise them but will not fail.
Method removed or streaming type changed	Error	Existing clients calling the removed method will receive connection errors. Streaming type changes break client-side stream handling.

Structural Drift Detection

Beyond explicit validation rules, the model uses FNV-1a structural hashing to detect when architectural artefacts have changed since they were last reviewed. Every model entity, schema, endpoint, and graph node has a structural hash computed from its significant fields (names, types, references). Governance blocks that reference these nodes store the hash at review time. When the hash changes, the reference is flagged as stale.

Node Type	Structurally Significant (Hashed)	Excluded from Hash
Model Entity	Label, properties (name, type for each)	ID, derivation paths, projections, visual properties
Schema	Name/title, extends list, fields (name, schemaId for each)	ID, lineage entries, descriptions
REST Endpoint	Name/title, request body schema ref, response schema refs, path/query param schema refs	ID, API ID, header params schema ref
Graph Node	Label, properties (name, type for each)	ID, position, colour, visual properties

Full Impact Analysis Pipeline

When you make any change to the model - rename a property, change a type, modify a key role, update a constraint, alter a relationship - the impact analysis pipeline traces the change through the entire dependency graph.

What the Compiler Catches

Consider what happens without model validation compared to what NeoArc catches at design time.

Change You Make	Without NeoArc	With NeoArc
Delete an entity that has FK references	Migration script fails. Downstream schemas break silently.	fk-target-missing error flags every broken FK immediately. Impact dialog shows all affected schemas and endpoints.
Rename a property used in 3 API schemas	API contracts serve the old field name. Clients break at runtime.	Impact analysis traces the rename through maps-to edges to every schema, endpoint, and view. Full blast radius shown before rename.
Change cardinality from 1:N to N:M	Existing FK constraints become invalid. Join queries return wrong results.	Edge change impact dialog flags this as dangerous. Shows affected schemas, views, and documentation that assume single-valued relationships.
Change a PK property's type from integer to uuid	FK type mismatches cascade through the model. Insert operations fail.	fk-type-mismatch errors appear on every FK property referencing this PK. Circular FK chain detection prevents cascading failures.
Remove an enum value from a property	Existing data using the removed value fails validation. gRPC clients decode it as unknown.	Proto breaking change detector flags enum-value-removed as a wire-format error. Schema drift detection flags the type change.
Add maxLength constraint to a string property	Database template resolves differently. Existing data may exceed new limit.	Parameterised type templates update (e.g., NVARCHAR(MAX) to NVARCHAR(255)). Data Views and API projections all reflect the constraint.
Delete a relationship between two entities	Derived schemas lose a join path. Navigation in documentation breaks.	Impact dialog shows every schema, view, and page that references this relationship. All dependents listed before deletion proceeds.
Mark a property as PII but forget compliance notes	Audit finds PII without documented handling. Compliance gap.	governance-pii-unencrypted info flag reminds you to add compliance notes before the next governance review.