https://www.boundaryml.com logo
🟡 Human-in-the-loop mechanism using check and ass...
# questions
v
Has anyone used @check and @assert syntax to design a human-in-the-loop mechanism for user approval?
• Title: TypeBuilder: no structured API for @check / @@check on dynamically-built schemas Summary When building dynamic schemas at runtime using BAML TypeBuilder’s structured API (addClass / addProperty), there appears to be no way to attach BAML validations (@check field checks or @@check class-level checks). This makes it hard to use checks for runtime validation / gating on dynamically injected types. What I’m seeing - The TypeBuilder JS/TS “builder” surface only supports setting the field type plus metadata like alias and description. - There are no methods to add checks to a field or a class (e.g., nothing like addCheck, check(...), etc.). - As a result, schemas created via addClass + addProperty cannot express @check / @@check. Evidence (API surface) - ClassPropertyBuilder exposes setType, getType, alias, description — but nothing check-related. - TypeBuilder exposes addClass, addEnum, and addBaml. Workaround - TypeBuilder.addBaml(...) can accept a class definition containing @check syntax (and parses successfully), but this requires injecting raw BAML text instead of using the structured builder API. That’s not always desirable (especially if the schema originates from untrusted input). Questions for maintainers 1. Is there an intended/supported way to define @check / @@check using the structured TypeBuilder API (without addBaml) 2. If not currently supported, is adding check support to TypeBuilder on the roadmap? 3. If addBaml is the recommended approach for checks, are there guidelines/best practices for safely generating/validating the injected BAML (especially for user-provided schemas)?
I recall that typebuilder is undergoing a refactoring. Is there any further progress? @Vaibhav (BAML 🐑)