Add `undefined` Field Type for Safer Text-First Template Creation

[LeoInTheLoop]

Background

In Accord Project templates, the text (grammar), model (.cto), and sample data are tightly linked.
Currently, when a user creates a new template starting from text, any undefined variables (e.g., {{customer}}, {{total}}) must already exist in the model.
If not, the system throws an error when running cicero parse or cicero trigger.

This strict model-text synchronization causes friction during text-first development — users must manually define every variable in the model before testing or previewing a simple template.

---

Proposed Feature

Introduce a new field type called undefined (behaving similarly to String), to act as a temporary placeholder type when variables in the text are not yet defined in the model.

Expected Behavior

1. When a user creates or edits grammar.tem.md and adds a new {{variable}} that is not found in the model:
   • The system automatically adds that variable to both the model and sample data.
   • The default type assigned is undefined.
2. The variable appears in the generated model as:

   o Undefined customer
   o Undefined total
   o Undefined status
   

3. In sample data:

   {
     "customer": "Undefined",
     "total": "Undefined",
     "status": "Undefined"
   }
   

4. The template compiles and parses without error, allowing users to iterate freely.
5. Users can later update the model to replace undefined with a concrete type (String, Double, etc.) once finalized.

---

Benefits

• Reduces template creation errors — Users won’t face missing-variable model errors during early drafts.
• Improves text-first workflows — Easier to go from raw text → working prototype → refined template.
• Accelerates onboarding — Especially helpful for non-technical users or business analysts working primarily in natural language.
• Supports iterative modeling — Developers can define variable semantics later, after validating the text logic.

---

Implementation Considerations

• Type Safety: The undefined type may internally map to String but should be marked (e.g., via metadata) as “auto-added” or “to be defined.”
• Compatibility: Existing templates should remain unaffected; fallback logic should only trigger when new variables are detected.
• UI Support: Editors like Template Studio could visually highlight auto-added fields and prompt users to confirm their final types.
• Docs Update: Add a section in Tutorial: Templates showing “Text-first template creation with undefined fields.”

---

Example Workflow

Text (grammar.tem.md):

Invoice for {{customer}}
Total amount: {{total}}
Payment status: {{status}}

Auto-generated model (model.cto):

asset InvoiceClause extends AccordClause {
  o Undefined customer
  o Undefined total
  o Undefined status
}

Auto-generated sample data (sample.json):

{
  "$class": "org.accordproject.invoice.InvoiceClause",
  "customer": "Undefined",
  "total": "Undefined",
  "status": "Undefined"
}

Users can later refine:

asset InvoiceClause extends AccordClause {
  o String customer
  o Double total
  o String status
}

---

Summary

This feature would make template creation smoother, especially for those starting from text.
It helps prevent runtime errors and aligns with Accord Project’s vision of bridging natural language contracts with formal logic and data models.

---

Suggested Labels: feature, enhancement, UX improvement

[Zeeshan3h3]

hey @LeoInTheLoop i find this issue in my domain and i attatched my proposed solution overview : Idea: Auto-generate Undefined Fields

Whenever Cicero detects a variable like {{something}} that is not defined in the model:

Instead of throwing an error,

It auto-creates that field in the model temporarily with a placeholder type — e.g. Undefined.

Proposed Implementation Steps Add an “Undefined” Type in the Parser

Add a lightweight type handler in Cicero’s model compiler:

concept Undefined { o String placeholder }

or even simpler — let Undefined internally map to String but with a metadata tag:

@autoAdded o String status

So internally it’s safe (since it’s still a String), but marked as something that should be defined later.

Modify Variable Resolution Logic

When parsing the text:

If a variable {{xyz}} is not found in the model, → Auto-inject it into the model as Undefined.

Example auto-generated entry:

o Undefined xyz

and in sample data:

"xyz": "Undefined"

This lets parsing continue successfully.

UI & Developer Tool Support

If used inside Template Studio, or via cicero parse CLI:

Show a warning, not an error:

⚠️ Added undefined field 'status' with type 'Undefined'

Highlight in the model editor to remind users to finalize types later.

4️⃣ Developer Refinement Step

When the template is stable, the user updates the model manually, for example:

o String customer o Double total o String status

and removes the temporary metadata

[ananyapahwa]

Hi , I’m new to open source and would love to work on this issue. Could you please assign it to me or confirm if it’s open for contribution?

[Aradhana2803]

Hi @LeoInTheLoop, @maintainers 👋 I’ve gone through the problem description and the discussion above, and I’m very interested in contributing to this feature.

Before starting, I’d like to confirm whether this issue is currently open for contribution.

My Proposed Approach (Concise & More Structured):

Introduce a lightweight Undefined placeholder type

Internally map it to String, but with metadata such as @undeclaredField to distinguish it from user-defined fields.

Ensures backward compatibility and safe parsing.

Extend variable-resolution logic

When Cicero encounters a variable in the grammar that is not present in the model: → auto-inject it into the model as Undefined → auto-populate sample data with "Undefined" → emit a non-blocking warning instead of an error.

Editor / Template Studio support

Highlight auto-added fields in UI.

Provide prompts to convert them to formal types later.

Developer validation step

Maintain a list of auto-added fields so final templates can warn “X undefined fields remain”.

This workflow keeps the text-first development smooth while preserving type-safety and model clarity.

If this direction aligns with the project’s expectations, I’d be happy to start working on a PR. Could you please assign this issue to me or confirm that it's available?

Thanks!