Skip to content

Add undefined Field Type for Safer Text-First Template Creation #822

@LeoInTheLoop

Description

@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

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