Questions and answers on data modeling, schemas, governance, and interoperability.
Showing questions 501-600 of 1000
Break the Taxonomy into manageable hierarchical sections, use search and filtering to navigate, import bulk terms via CSV or SKOS rather than clicking each, assign owners per branch for distributed stewardship, and keep the Graph view collapsed to top levels by default. Large Taxonomies are maintenance projects in their own right and benefit from the same discipline you would apply to a large codebase.
IRIs give each Taxonomy term a globally unique identifier, making cross-system references unambiguous. When your Disease Taxonomy uses SNOMED CT IRIs, any system that also references SNOMED CT aligns automatically without manual mapping. This is the foundation of federated semantics — local terms mean the same thing everywhere they appear, because the IRI is the authoritative identity.
Track changes through CoreModels' built-in history and Git integration, apply semantic versioning principles to the Taxonomy as a whole, mark deprecated terms explicitly rather than deleting them, and communicate changes through release notes that list added, removed, and renamed terms. A Taxonomy is a contract with every schema that references it, so version discipline matters.
Publish the Taxonomy in a canonical Space, export it as SKOS or JSON-LD, and import into other Spaces as needed. For tight coupling, reference the canonical Taxonomy directly through cross-space relations; for loose coupling, copy and maintain independently with periodic sync. The right choice depends on whether drift between copies is acceptable for your use case.
Taxonomies enforce controlled vocabularies at the schema level, so governance decisions about what terms are allowed, what they mean, and who can add new ones travel with the data automatically. Without Taxonomies, governance policies live in wikis that editors never read; with Taxonomies, compliance is structural rather than aspirational.
When multiple content Types reference the same Taxonomy through ControlledList, they share tag values — an Article tagged Healthcare and a Product tagged Healthcare use the identical term, enabling consistent filtering, search, and cross-type recommendations. Without shared Taxonomies, each Type invents its own tag list and aggregation becomes unreliable.
Use clear, domain-appropriate names in singular form (StudyType, AudienceLevel, Region), avoid redundant suffixes like Taxonomy or List, use consistent casing, and pick names that will still make sense to someone joining in two years. For term names within a Taxonomy, favor short, unambiguous labels with fuller definitions in the term description.
Neo Agent can propose terms from natural-language descriptions, suggest hierarchical structure, identify likely missing terms given the existing ones, and map your Taxonomy against external standards. You review and accept or adjust the suggestions, so governance stays in human hands while routine expansion becomes much faster.
Taxonomies appear in the Taxonomies panel with their term hierarchy visible as a tree, and in the Graph view connected to the Elements that reference them through ControlledList relations. The Workbench supports detailed editing of individual terms. Visual display makes hierarchy issues and misclassifications obvious in ways that flat lists cannot.
AI systems consume Taxonomy-tagged content far more reliably than free-text — facet-aware retrieval, filtered RAG, and precise entity recognition all depend on controlled classification. Exporting Taxonomies as SKOS or JSON-LD makes them directly consumable by AI pipelines, which is why Taxonomy discipline is becoming a differentiator for AI-ready content platforms.
A Relation is a typed edge connecting two nodes in the graph — typically a Type to an Element, a Type to another Type, or an Element to a Taxonomy. An Element is a node representing a property definition; a Relation is the edge expressing how nodes connect. Both are first-class, but they serve different roles: Elements describe fields, Relations describe structural connections.
A RelationGroup is a named category that classifies Relations by purpose — domainIncludes for attachment, SubClassOf for inheritance, ControlledList for Taxonomy linkage. Grouping relations by semantic role makes the graph navigable, queryable by relation type, and visually meaningful. Without RelationGroups, every edge would look alike and structural meaning would be lost.
The domainIncludes RelationGroup expresses that an Element is a property of a Type — the Type has this field, or the Type is in the Element's domain in ontology terms. Attaching an Element to a Type creates a domainIncludes relation, which during export becomes a property listing in JSON Schema and a schema.org domainIncludes declaration in JSON-LD.
The rangeIncludes RelationGroup declares that a Type is a valid value type for an Element — the Element can accept instances of this Type as its value. A blogPost Element that references Author via rangeIncludes is saying the value of blogPost.author is an instance of Author. This is standard ontology vocabulary borrowed from schema.org.
The SubClassOf RelationGroup expresses inheritance — a child Type is a specialization of a parent Type, inheriting its Elements and rules. A ScientificArticle SubClassOf Article means every ScientificArticle is an Article with additional specialization. On export, this becomes allOf composition in JSON Schema and rdfs:subClassOf in JSON-LD.
Create a new RelationGroup with a clear name describing its purpose such as derivedFrom or mappedTo, attach a description and any needed metadata, and start using it in relations across your Types. Custom RelationGroups are first-class and participate in queries, visualizations, and exports the same way built-in ones do.
Attaching an Element to a Type creates a Relation of the domainIncludes RelationGroup between them. Removing the attachment deletes the Relation. This structural clarity is why CoreModels can show a graph view — every attachment is visible as an edge, not buried inside a property definition the way it is in textual JSON Schema.
Types connect to each other through Relations like SubClassOf for inheritance, rangeIncludes for value type references, or custom RelationGroups for domain-specific links such as mappedTo. Each connection type carries its own semantics, which the RelationGroup declares. The result is a rich network of typed edges, not a tangle of anonymous references.
An Element connects to a Taxonomy through a ControlledList Relation, expressing that the Element accepts only terms from that Taxonomy. This Relation is the structural counterpart to an enum declaration in JSON Schema, but more expressive because the Taxonomy itself is a first-class node with its own structure and metadata.
In ontology terms, the domain of a property is the set of Types it can belong to (who has this property), and the range is the set of Types or values it can point to (what values are valid). CoreModels encodes these as the domainIncludes and rangeIncludes RelationGroups, matching schema.org conventions and enabling standards-aligned export.
Use a domainIncludes relation to attach the containing Element to the parent Type, and if the Element references another Type, use rangeIncludes to declare the value type. An Article has-a author is modeled by attaching an author Element to Article (domainIncludes) and declaring its range as Author (rangeIncludes).
Use a SubClassOf relation from the child Type to the parent Type. A ScientificArticle is-a Article is modeled by adding a SubClassOf relation from ScientificArticle to Article. The child inherits the parent's Elements and rules, and the relationship survives all exports as standard inheritance.
Use rangeIncludes to express that a Type or Element can have a certain value type. If a Publication's format can be either PrintFormat or DigitalFormat, you can attach a format Element to Publication with rangeIncludes both PrintFormat and DigitalFormat. The disjunction is captured structurally and maps to oneOf or anyOf on export.
The ControlledList RelationGroup links an Element to a Taxonomy, declaring that the Element accepts only terms from that controlled vocabulary. This is the primary mechanism for enforcing controlled values on fields, and it is what distinguishes a Taxonomy-linked Element from a free-form text Element.
CoreModels supports Relation-level metadata through a combination of custom RelationGroups and Mixins attached to the Relation. This lets you attach properties like confidence, effectiveDate, or source to the connection itself, not just the nodes it joins. It is analogous to edge properties in a labeled property graph.
The Graph view renders Relations as labeled edges between nodes, with edge color or style distinguishing RelationGroups. Hovering over an edge shows its type, direction, and any attached metadata; clicking navigates to either endpoint. This visualization turns structural questions into visual inspection, which is dramatically faster than tracing through text.
In the Types Grid, Type detail view, or Graph view, click a Relation to open its target. CoreModels tracks navigation history so you can step back, and search lets you jump directly to any node. For complex traversals, the Graph view's interactive mode lets you drag edges to expand or collapse subgraphs.
CoreModels flags cyclic SubClassOf chains explicitly because they are meaningless (nothing can be its own ancestor). For other relations, cycles may be intentional such as self-references for tree structures. Review cycles in the Graph view and apply conventions or Mixins to mark which are intended and which are bugs.
On export, domainIncludes relations become property listings in the parent Type, SubClassOf becomes allOf composition, rangeIncludes becomes type or $ref declarations on the relevant property, and ControlledList becomes enum constraints. Every RelationGroup has a defined export mapping, so the graph's semantic structure translates faithfully into standard JSON Schema.
On JSON-LD export, every Relation becomes an RDF triple with the source as subject, the RelationGroup as predicate, and the target as object. SubClassOf maps to rdfs:subClassOf, domainIncludes and rangeIncludes map to their schema.org equivalents, and custom RelationGroups become custom predicates. The result is valid linked data consumable by any RDF tool.
Create a custom RelationGroup with a descriptive name and clear purpose rather than overloading an existing one. Document what the custom RelationGroup means and when to use it. CoreModels treats custom RelationGroups as first-class, so they participate fully in the graph — views, exports, queries, and Neo Agent all understand them.
Mappings between schemas — HL7 FHIR to schema.org, for example — are expressed as Relations of a custom mappedTo RelationGroup between Types or Elements across Spaces. These mapping Relations are queryable, visualizable, and exportable, giving you a machine-readable alignment layer rather than a spreadsheet of text pairs that drift over time.
Look for Relations with similar source-predicate-target patterns; extract repeated structures into reusable Components or shared Elements; promote ad-hoc custom RelationGroups into canonical ones where sensible. The goal is fewer, clearer, more semantic connections rather than many similar-but-different ones scattered across the graph.
Use the Graph view to inspect all Relations of a given RelationGroup, filter by source or target, and look for missing or unexpected connections. Neo Agent can also help by flagging inconsistencies such as Elements with no Type attachments or SubClassOf chains that skip expected intermediate levels. Regular audits catch structural drift before it compounds.
Relations are what make CoreModels a graph rather than a collection of disconnected definitions. Every structural concept — attachment, inheritance, controlled vocabulary, mapping — is a Relation with a defined RelationGroup. This uniform treatment is why CoreModels can represent relational, document, and semantic models in one platform, export to many formats, and support queries across the entire model.
A Mixin is a reusable bundle of rules, metadata, or behavior that attaches to Types or Elements without being a Type itself. Where a Type represents a domain concept, a Mixin represents orthogonal properties like validation rules, documentation hints, or policy flags. Mixins compose: a Type can have many Mixins, each contributing different aspects, which is cleaner than stuffing everything into inheritance.
In the Types Grid or the detail view of a Type or Element, apply a Mixin and configure its value. The Mixin attaches via a relation, carries its data, and participates in export. Multiple Mixins can coexist on the same Type or Element, and the same Mixin can be applied at different attachment points with different values.
The required Mixin, attached to an Element at its attachment to a specific Type, marks the Element as mandatory for instances of that Type. On JSON Schema export, the Element's name appears in the Type's required array. Required is per attachment rather than global, so the same Element can be required for Article and optional for Draft.
The minLength Mixin sets a minimum character count on a string-valued Element. Use it to prevent empty or near-empty submissions when business rules require real content — a title with minLength 3, a description with minLength 20. On export, this becomes the minLength keyword in JSON Schema, applied to the relevant property.
Each Mixin has a defined mapping to one or more JSON Schema keywords. When you export, CoreModels walks each Type and Element, collects their attached Mixins, and emits the corresponding validation constraints. The effect is that Mixins are the authoring surface for rules; the exported JSON Schema is the consumption surface.
The JSON Schema Rules Mixin carries complex validation rules that cannot be expressed through simple Mixins — conditional rules, combinations like allOf, anyOf, oneOf, and references across Types. It is the structured storage backing the Rule Builder, and it preserves full expressiveness during JSON Schema round-trips.
The JSON Schema Mixin surfaces the raw JSON Schema fragment that will be emitted for a Type or Element, letting advanced users inspect or override it directly. When added as a column in the Types Grid, it provides a fast way to preview what the export will produce, which is invaluable during complex rule authoring and troubleshooting.
Open the configuration side panel in the Types Grid, select the Mixins you want to display as columns, and apply them to Type Columns, Element Columns, or both. Columns make Mixin values visible and editable inline for every Type or Element, which is dramatically more efficient than opening each detail view individually.
Select multiple Elements in the grid, apply the Mixin in one operation, and configure its value. CoreModels supports batch operations that propagate the Mixin to every selection. This is essential for consistency — applying the same validation rule across similar Elements without clicking each individually.
Instead of stuffing all rules into a single monolithic definition per Type, Mixins let you layer independent concerns — validation, documentation, lifecycle, governance — each as a separate Mixin. You compose the final behavior by combining the Mixins you need. This mirrors aspect-oriented programming and keeps each rule focused and reusable.
An Attribute is simpler metadata attached to a node without rule semantics — a key-value pair that carries information for documentation, tooling, or human reference. A Mixin is richer: it is a named, defined pattern with known semantics that drives validation or other behavior. Attributes are notes; Mixins are rules.
Attributes hold descriptive information — ownership tags, versioning notes, documentation hints — that does not translate to validation keywords but does surface in documentation, governance reports, and search. They let you annotate the model with information that matters for humans without cluttering the formal rule surface.
Each Mixin with a JSON Schema mapping contributes to the exported schema — required to the required array, minLength and maxLength to their keywords, pattern to pattern, and complex rules through the Rule Builder into allOf, oneOf, if/then/else constructs. Mixins with no JSON Schema mapping remain as annotations or are omitted based on the export configuration.
Mixins relevant to JSON-LD — datatype declarations, cardinality, language tags — contribute to the @context and property definitions. SKOS-related Mixins apply to Taxonomies. Mixins specific to JSON Schema validation do not appear in JSON-LD; CoreModels exports each format in its native idiom.
Mixins inherit through SubClassOf by default — a rule attached to a parent Type applies to every descendant. Children can override by applying their own Mixin with a different value, which takes precedence at that attachment point. This layering matches how aspects combine in aspect-oriented programming.
When a child Type applies a Mixin that the parent also applied, the child's value wins at that attachment point. For Mixins that are additive rather than override-based, contributions from multiple levels combine. The Graph view and Mixin inspection show the effective value along with its source, so conflicts are visible and resolvable.
Define the Mixin with a name, describe what it means, specify its configurable fields and their data types, declare whether and how it maps to export formats, and make it available in the Space. Custom Mixins let you encode organization-specific rules — sensitivityLevel, dataRetentionDays, owner — as first-class model elements.
The cmId is the internal identifier CoreModels uses to recognize which Mixin a JSON Schema keyword corresponds to during import. When importing a schema with minLength, CoreModels looks up the cmId for minLength and attaches the matching Mixin with the imported value. This mapping table is what makes round-trip imports and exports semantically stable.
Check the Mixin's attachment point (is it on the Element or on the Type?), verify its value in the Types Grid or detail view, export to JSON Schema and inspect the output, and compare with expected results. The JSON Schema Mixin column preview is often the fastest way to see what CoreModels will actually emit for a given configuration.
Because Mixins are structured metadata, governance tooling can query across them — list every Type with a sensitivityLevel Mixin, find every Element without an owner Mixin, flag Types missing required governance tags. Combined with change tracking, this gives governance teams a machine-readable view of model health rather than a spreadsheet that rots.
Policies like all PII Elements must have a sensitivityLevel Mixin or all public Types must have an owner Mixin become automated checks in CI. Violations are detected at schema-design time, not in production. Mixins are what turn governance from prose into enforceable structure.
Every Mixin carries its own description and usage notes, ideally explaining why it exists, when to apply it, and what it affects on export. For custom Mixins specifically, documenting the intent is essential — a Mixin without documentation becomes confusing metadata that contributors either ignore or misuse.
Mixins are the schema-modeling counterpart of aspects: cross-cutting concerns like validation, documentation, and governance attached non-invasively to many nodes. Just as aspects keep logging and security out of core business logic, Mixins keep these concerns out of Type and Element definitions — each focused on its own purpose and composable with the others.
Define a canonical set of Mixins with clear documentation, avoid reinventing equivalents, review new custom Mixins before they proliferate, apply Mixins through templates and defaults where possible, and periodically audit for inconsistencies. Without these practices, teams produce near-duplicate Mixins that mean slightly different things, defeating the composability benefit.
One Mixin definition applied across many Types or Elements is the DRY pattern in action — rules defined once, reused everywhere, updated in a single place. Combined with reusable Elements and Components, Mixins are how CoreModels schemas avoid the copy-paste duplication that plagues hand-authored JSON Schema files.
The Rule Builder is a visual interface for authoring and editing complex JSON Schema validation rules — allOf, anyOf, oneOf, not, if/then/else, and nested combinations. It solves the problem that these keywords are expressive but hard to write correctly by hand, especially at scale. The Rule Builder lets modelers compose rules through a UI rather than debugging raw JSON.
Instead of editing deeply nested JSON Schema text, the Rule Builder presents combination keywords as named, expandable blocks with child rules inside them. Building an allOf with two inner rules is a few clicks; the equivalent raw JSON is error-prone. The visual structure mirrors the logical structure, so the intent stays obvious.
The Rule Builder supports all five combination and conditional keywords — allOf, anyOf, oneOf, not, if/then/else — plus nested combinations of them, property constraints, and references to other Types. This covers the full expressive power of JSON Schema validation without dropping to text editing.
Open the Type or Element detail and navigate to its rules section; the Rule Builder displays the rule tree with each combination keyword shown as a block and each leaf as a constraint. Expand or collapse branches to navigate. Large rule sets can be filtered or searched within the builder itself.
In the Rule Builder, add a new rule, choose its keyword (if/then/else, for example), and configure the inner schemas. For if/then/else, you specify the condition that triggers the then branch, with an optional else. The builder validates the rule structure as you go, catching syntactic issues before export.
Select the rule in the tree and apply the remove or edit action. Before removal, the builder can show impact — which Types or exports depend on this rule — so you can assess consequences. Edits are tracked in change history, making it easy to roll back if the new rule behaves unexpectedly.
The Rule Builder is the editing surface for the JSON Schema Rules Mixin, which is the storage format for complex rules on Types and Elements. Adding a rule in the builder writes to the Mixin; the Mixin is what exports to JSON Schema. This separation of concerns means the storage format stays stable while the UI can evolve.
The builder renders nested rules as an indented tree, each level visually distinct. Color coding distinguishes keyword types, and collapsible blocks keep the view manageable even for deep nesting. When a rule tree becomes genuinely unwieldy, that is usually a signal to refactor — extracting inner rules into reusable Types, for example.
The Rule Builder abstracts away the JSON Schema syntax entirely. Authors pick from named keyword options, configure each through form inputs, and see immediate feedback. Someone who has never written JSON Schema can author valid complex rules through the builder, which is a major enablement win for mixed-skill teams.
Create or attach an Exemplar to the Type under test, open the validation view, and see whether the Exemplar passes the rule. For invalid cases, the validation output shows which rule failed and why. This turns Exemplars into executable tests for the schema, catching regressions immediately when a rule change breaks previously valid content.
Simplify the rule to isolate the matching clause, test each branch of a combination independently, provide small positive and negative examples, and use the JSON Schema Mixin preview to see the emitted constraint. For if/then/else rules that never trigger, the usual culprit is an overly strict condition. Visual inspection in the builder often makes the bug obvious.
Attach a description to the rule explaining why it exists and what it enforces, link to external requirements or tickets where relevant, and use meaningful naming for related Types and Elements. A rule without documentation is almost impossible to safely modify six months later, and the cost of documenting is trivial compared to the cost of forgetting.
Simple rules live in simple Mixins — required, minLength, pattern — applied directly. Complex combinations and conditionals live in the Rule Builder under the JSON Schema Rules Mixin. Together they cover the full spectrum of JSON Schema expressiveness, each with an authoring surface matched to the complexity of the rule.
Raw JSON Schema with if/then/else nested inside allOf inside oneOf is notoriously hard to read. The Rule Builder mitigates this by rendering the logical structure visually, with named blocks and clear hierarchy. Even intrinsically complex rules are much more readable when their structure is explicit rather than encoded in indentation.
Import the JSON Schema containing the rules; CoreModels parses combination and conditional keywords into the Rule Builder's structured representation. Review the imported rules in the builder to confirm correctness, adjust naming or structure for clarity, and save. The migration is lossless when the source schema is valid.
When importing multiple schema files, $ref links between them resolve into graph relations, and rules within each file become Rule Builder entries. The builder handles references across files transparently, so you see the full rule tree even when it spans multiple source documents. Complex multi-file schemas become navigable in a way the raw files never were.
In the Rule Builder, reference another Type by selecting it from the Type picker rather than typing a $ref manually. The reference is stored as a relation, which keeps the target stable through renames. On export, the relation becomes the appropriate $ref in JSON Schema, pointing at the target Type's schema location.
The export process walks each Rule Builder entry and emits the corresponding JSON Schema keyword with its configuration — allOf, anyOf, oneOf, not, if/then/else, properties, references. The exported schema is standard JSON Schema consumable by any validator, and a round-trip (export then re-import) produces an equivalent rule tree.
In the Types Grid, rules are surfaced as columns (typically the JSON Schema Rules Mixin) and can be filtered on. In the Graph view, Types with complex rules can be visually marked, and rule-specific relations (such as references to other Types from within a rule) appear as edges. The views complement the Rule Builder rather than replace it.
By making complex validation rules tractable to author and maintain, the Rule Builder raises the ceiling of what teams enforce at the schema level. Rules that would be skipped because they were too hard to write in raw JSON Schema now get implemented, which translates directly into higher data quality downstream — fewer bad payloads, fewer integration bugs, fewer expensive late surprises.
Neo Agent is the AI assistant built into CoreModels, grounded in your current Project and Space. It can propose Types, Elements, and Taxonomies from descriptions, suggest mappings between schemas, draft documentation, identify inconsistencies, and automate routine refactoring. Unlike a generic chatbot, it understands your actual model and respects your governance rules, making its suggestions directly actionable.
Neo Agent reads the graph directly — every Type, Element, Taxonomy, Mixin, and Relation — and can propose changes that are themselves expressed as graph operations. You see proposed additions, renames, and deletions in the same visual surface as manual edits, and approve or modify them before they are applied. It operates as a first-class citizen of the modeling workspace.
Common accelerations include bootstrapping a schema from a description, expanding a Taxonomy, finding candidate extractions for reuse, suggesting Mixins based on field patterns, drafting field descriptions, proposing mappings between source and canonical schemas, and generating test data. Essentially, the mechanical parts of modeling where a human reviewer is still needed but the drafting could be automated.
Neo Agent observes the patterns in your existing Types — what Elements they share, what conventions they follow, what is conspicuously missing — and proposes Elements that would fit the pattern. For example, a Type with title and body but no publication date in a schema where most content Types have one might prompt a suggestion to add it, with the appropriate Mixins.
Describe the domain in plain language — the entities involved, their key attributes, how they relate — and Neo Agent proposes an initial schema with Types, Elements, and Taxonomies. You review, adjust, and accept. This cuts the blank-canvas problem significantly; refining a reasonable first draft is much faster than building from nothing.
When you have two schemas that need aligning — a source in HL7 FHIR and a target in schema.org, for example — Neo Agent can propose candidate mappings at the Type and Element level based on names, definitions, and structural similarity. You review and confirm each mapping, so governance stays in your hands but the routine mechanical work is automated.
Neo Agent respects the existing Mixins, naming conventions, and structural patterns in your Space, proposing changes consistent with what is already there. You can also provide explicit guidance — preferred vocabularies, naming style, required Mixins — through Project-level configuration. And every suggestion is a proposal, never an automatic change, so a human review gate is always in place.
Neo Agent surfaces proposals as structured diffs against the current graph — additions, removals, modifications — which you can accept in full, accept selectively, or reject entirely. Accepted changes go through the same audit trail as manual edits, with Neo Agent identified as the source. Rejected proposals leave no trace on the model.
Exemplars provide concrete evidence of intended use, which Neo Agent reads alongside the schema itself to ground its proposals. An Exemplar demonstrating an Article with tags helps Neo Agent understand your tag conventions when proposing similar Elements on a new Type. Exemplars are not just tests; they are guidance for the AI.
Paste or describe a list of terms, optionally with hierarchy hints, and Neo Agent proposes a full Taxonomy structure — terms, hierarchical relationships, optional aliases and definitions. You review the result in the Graph view, adjust where needed, and commit. What would take an hour of manual term-by-term creation becomes a few minutes of review.
After import, Neo Agent can review the imported schema, suggest consolidation of near-duplicate Elements, propose better names for cryptic fields, identify candidate shared Components, and flag inconsistencies. The raw import is structurally faithful to the source; Neo Agent's post-import pass brings it up to the organizational standard quickly.
Neo Agent drafts descriptions for Types, Elements, and Taxonomies based on their names, relationships, and the wider schema context. You review and refine. Documentation debt — fields and Types with cryptic names and no explanations — is one of the most chronic schema problems, and AI-drafted documentation is a practical way to catch up.
Neo Agent can scan the Space for inconsistencies — naming patterns that differ for no reason, Mixin applications that diverge across similar Elements, Types missing expected metadata — and propose corrections in bulk. A manual consistency review takes hours; a Neo Agent review takes minutes, and the human focuses on judgment calls rather than finding the issues.
Be specific about intent, reference concrete Types or Elements by name, state constraints explicitly such as must inherit from Article, and provide examples when asking for something open-ended. Clear prompts produce better proposals, and iterating — refining the prompt based on the first response — is usually faster than starting over.
Neo Agent can use the CoreModels MCP server to read and propose changes, and can consult external MCP servers like the Ontology Lookup Service for domain vocabularies. This makes Neo Agent extensible: connecting new MCP servers adds new capabilities without changing Neo Agent itself. It is how the agent reaches beyond the local Project to authoritative external data.
Modelers shift from producing every definition by hand to curating AI-drafted proposals, which raises throughput and lets them focus on judgment-heavy work — governance, architecture, stakeholder alignment. The expertise required grows rather than shrinks, because reviewing AI proposals demands deep domain understanding; mechanical drafting becomes less of the job.
AI can propose plausible-looking names with subtly wrong semantics, overfit to one team's conventions in ways that do not generalize, miss constraints that live in unwritten domain knowledge, and produce near-duplicates of existing Elements rather than reusing them. Active review catches these; passive acceptance compounds them. Treat every proposal as a draft, never as finished work.
By lowering the technical barrier. A subject-matter expert who can describe their domain in words can collaborate with Neo Agent to produce an initial schema without needing to understand JSON Schema syntax or modeling conventions. The modeler then refines. This opens schema work to a broader set of contributors, which is especially valuable in domain-heavy industries like healthcare and finance.
When Neo Agent proposes new Types or Elements, it applies the Mixins your governance rules require — ownership tags, sensitivity levels, mandatory descriptions — based on the conventions visible in the existing Space. If required Mixins are configured at the Project level, proposals without them are flagged for correction before they can be accepted.
Neo Agent surfaces the ambiguity rather than guessing — asking clarifying questions, presenting alternative proposals, or highlighting that two directions are possible. This is a crucial design principle: an agent that silently picks a direction in ambiguous situations becomes a source of surprise. Explicit clarification keeps the human in the loop.