gem-hunter

This is a experimental library that aims to provide templating composition and type/runtime safe interpolation for tagged template literals by leveraging Zod's validation ecosystem.

At definition time this library pre-flattens nested renderable structures and tries to infer the template types for a better DX.

At runtime this library validates your templates inputs against the zod schemas definitions and merges nested templates into a single interpolation.

The core functionality consists in three abilities:

• Enable composition by nesting other renderables
• Automatically infer the type of variables your template expects
• Validate those variables against the zod schemas

Typed, validated, composable interpolation trees for TypeScript.

How do you write multi-purpose prompts, database queries, GraphQL mutations and complex templated structures that are simultaneously composable, type-safe AND give you explicit control over what gets parameterized?

Zod Tag provides a seriously good pattern for a real problem: safe template parameterization. By letting selector functions encode architectural decisions in a natural templating flow that clearly distinguishes what is protocol structure from parameterized value right on your code.

When you generate code from templates (SQL queries, GraphQL, LLM prompts, [or concatenate strings]) you constantly face a decision:

• Structure: what's part of the query/prompt itself?
• Values: what's user input that should be parameterized?

Most tools force you into one extreme:

zod-tag gives you both: explicit, visible control over what's structure and what's a value, with types enforcing the distinction.

The library separates concerns at the point of use:

• Renderables in selectors = template structure (protocol, language specific, syntax keywords, hardcoded/trusted data)
• Schemas or primitives in selectors = parameterized values (user input, IDs, dates, other values)

Example: Conditional SQL Structure

const createUserAndProfile = zt.z({
  userId: z.uuid(),
  bio: z.string().optional(),
})`
  INSERT INTO users (id) VALUES (${e => e.userId});

  ${e => e.bio
    ? zt.t`INSERT INTO profiles (user_id, bio) VALUES (${e => e.userId}, ${e => e.bio})`
    : zt.t``
  }
`
createUserAndProfile.render({ userId: crypto.randomUUID(), bio: 'user profile bio' })
// bio provided:
// → INSERT INTO users (id) VALUES ($1);
//   INSERT INTO profiles (user_id, bio) VALUES ($2, $3)
// args: [userId, userId, bio]

createUserAndProfile.render({ userId: crypto.randomUUID() })
// bio omitted:
// → INSERT INTO users (id) VALUES ($1);
// args: [userId]

The selector for bio doesn't return the bio text, it returns an entire INSERT or an empty template. The bio itself stays a runtime validated parameterized value. The conditional structure is visible, auditable, and type-checked.

Zod Tag actually returns a interpolation tuple with [strings: string[], ...values: unknown[]], this means it's agnostic in terms of database, client, syntax or anything, the only dependency is Zod v4.

Slop Test - repository pattern from repo.slop-test.ts

class UserRepository extends Repository {
    constructor() {
        super('users');
    }

    // Create a new user
    create = this.sql({
        id: z.uuid().optional().default(() => crypto.randomUUID()),
        name: z.string().min(1).max(255),
        email: z.email(),
        role: z.enum(['admin', 'user', 'guest']).default('user'),
    })`
    INSERT INTO ${this.table} 
      (id, name, email, role)
    VALUES (
      ${e => e.id},
      ${e => e.name}, 
      ${e => e.email}, 
      ${e => e.role}
    )
    RETURNING *
  `;

    // Find user by ID
    findById = this.sql({
        id: z.uuid(),
    })`
    SELECT * FROM ${this.table}
    WHERE id = ${e => e.id}
  `;
}

Slop Test - persona/format/severity block composition from prompt-2.slop-test.ts

Slop Test - math calculator from pattern-matching-function-definitions.slop-test.ts

// ============================================================================
// 1. PURE MATH — stateless, every branch returns a single number value
// ============================================================================

const math = zt.match('fn', {
    add: zt.z({ a: z.number(), b: z.number() })`${e => e.a + e.b}`,
    sub: zt.z({ a: z.number(), b: z.number() })`${e => e.a - e.b}`,
    mul: zt.z({ a: z.number(), b: z.number() })`${e => e.a * e.b}`,
    div: zt.z({ a: z.number(), b: z.number().min(Number.EPSILON) })`${e => e.a / e.b}`,
    pow: zt.z({ base: z.number(), exp: z.number().int() })`${e => Math.pow(e.base, e.exp)}`,
    clamp: zt.z({ val: z.number(), min: z.number(), max: z.number() })`${e => Math.max(e.min, Math.min(e.max, e.val))}`,
    neg: zt.z({ x: z.number() })`${e => -e.x}`,
    abs: zt.z({ x: z.number() })`${e => Math.abs(e.x)}`,
    sqrt: zt.z({ x: z.number().min(0) })`${e => Math.sqrt(e.x)}`,
})

type MathFn = IRenderableKargs<typeof math>

Slop Test - npc dialog state machine npc-dialog-state-machine.slop-test

A IRenderable<K, V> is a pure function from validated input to a structural tuple [strings, ...values]. Compose them like algebraic operations.

Every ${} in your template is a hole and receives the validated arguments. Its return type decides how it's treated:

The selector function e => ... isn't just transforming data - it's classifying what becomes structure and what becomes a parameterized value.

This means you see the structure/value boundary in your code. Types enforce that you don't accidentally parameterize keywords or inline user input.

Important: zt.z(shape): the shape schema is created with a loose strategy

Each of these is a mathematically well-behaved operation - they compose predictably and follow laws:

• zt.empty + anything = anything (identity)
• (a + b) + c = a + (b + c) (associativity)
• zt.map(list, t, id) = zt.map(list, t, id) (map with identity is identity)
• zt.bind(t, k).render() = t.render(k) (bind then render = render with bound kargs)

• zt.t...: Create a renderable from a tagged template literal
• zt.z({ shape })...: Create a renderable with a Zod shape for loose object schema with keyword arguments
• zt.p(name, renderable)...: Create a renderable with kargs scoped at key name of parent keyword arguments
• zt.empty: The identity renderable (monoidal identity)

• zt.match(discriminator, cases): Pattern-matched dispatch
• zt.bind(renderable, kargs): Partial application
• zt.map(list, renderable, mapFn, separator?): Functorial lift
• zt.join(list, separator): Monoidal concatenation
• zt.if(condition, renderable): Conditional rendering

• zt.p(name, schema, transform?): Named keyword parameter
• zt.unsafe(schema, value): Validated structural constant

When you write:

const user = zt.z({ name: z.string() })`Hello ${e => e.name}`
const bound = zt.bind(user, { name: 'Alice' })
const mapped = zt.map(['Alice', 'Bob'], user, name => ({ name }), zt.t` - `)

You're doing following things:

"Functor" (a context that holds a value):

The context is "this value needs validation"

"Map" (apply a function without leaving the context)

You're transforming the value while keeping the validation requirement

"Monad" (when a wrapped thing produces another wrapped thing, flatten them)

The expression zt.bind(user, { name: 'Alice' }) takes a renderable and returns a renderable (not a renderable of a renderable)

"Applicative" (combine wrapped values where the wrappers are independent)

Each ${} hole in a template is independent, they all get the same kargs but don't depend on each other's outputs

"Sum type"

Depending on runtime data, you pick one wrapped value or another

"Identity element" or "Monoid identity"

It composes with anything and leaves it unchanged

• "Monoid" (a way to combine two things of the same type with an identity)

The expression zt.join(items, sep) combines renderables with a separator

The rest of this document covers the full API and advanced patterns, but the above illustrates the central design decision: selectors classify structure vs. values.

npm install zod-tag

import { z } from 'zod'
import { zt } from 'zod-tag'

const user = zt.z({
    firstName: z.string(),
    lastName: z.string(),
})`
    Hello user, your full name must be: ${e => `${e.firstName} ${e.lastName}`}
`

user.render({ firstName: 'John', lastName: 'Doe' })
// -> [['\n    Hello user, your full name must be: ', '\n'], 'John Doe']

// Now you can interpolate raw, escape the values, derive this interpolation into other format or delegate it to other tagged template literals

graph TD
    %% Entry points
    subgraph "Constructors"
        zt_t["zt.t<br/>Tagged Template"]
        zt_z["zt.z<br/>Schema Shape"]
        zt_p["zt.p<br/>Named Parameter"]
        zt_empty["zt.empty<br/>Identity"]
        zt_unsafe["zt.unsafe<br/>Trusted Structure"]
    end

    %% Core Flow
    zt_t --> IR["IRenderable<br/>(validated, composable)"]
    zt_z --> IR
    zt_p --> IR
    zt_empty --> IR
    zt_unsafe --> IR

    %% Combinators
    subgraph "Combinators"
        zt_bind["zt.bind<br/>Partial Application"]
        zt_map["zt.map<br/>Functor Lifting"]
        zt_join["zt.join<br/>Monoidal Concat"]
        zt_if["zt.if<br/>Conditional"]
        zt_match["zt.match<br/>Pattern Match"]
    end

    IR --> zt_bind --> IR2["IRenderable<br/>(no kargs)"]
    IR --> zt_map --> IR3["IRenderable<br/>(list → single)"]
    IR --> zt_join --> IR3
    IR --> zt_if --> IR4["IRenderable<br/>| zt.empty"]
    zt_z & zt_t --> zt_match --> IR5["IRenderable<br/>(discriminated)"]

    %% Format Utilities
    subgraph "Output"
        render[".render(kargs)"]
        IR --> render
        render --> tuple["[strings, ...values]"]

        zt_n["zt.$n → $0, $1..."]
        atIndex["zt.atIndex → @0, @1..."]
        debug["zt.debug → raw string"]

        tuple --> zt_n
        tuple --> atIndex
        tuple --> debug
    end

    %% Type Helpers
    subgraph "Types & Guards"
        isRenderable["isRenderable()"]
        opaque["zt.opaque()"]
        IR --> isRenderable
        IR --> opaque --> IR6["IRenderable<br/>(output hidden)"]
    end

    %% Styling
    classDef constructor fill:#1a365d,stroke:#63b3ed,color:#bee3f8
    classDef combinator fill:#1c4532,stroke:#68d391,color:#c6f6d5
    classDef output fill:#744210,stroke:#f6e05e,color:#fefcbf
    classDef types fill:#553c9a,stroke:#b794f4,color:#e9d8fd

    class zt_t,zt_z,zt_p,zt_empty,zt_unsafe constructor
    class zt_bind,zt_map,zt_join,zt_if,zt_match combinator
    class zt_n,atIndex,debug,render,tuple output
    class isRenderable,opaque,IR6 types

The main namespace. All functionality is accessed through zt:

import { zt } from 'zod-tag'

Creates a IRenderable from a tagged template literal with no base schema. The type of expected keyword arguments is inferred entirely from interpolated values (inline schemas, zt.p, nested renderables).

// Static — no interpolation values, no kargs
const static = zt.t`Hello World`
static.render() // → [['Hello World']]

// With inline schema — kargs inferred from `zt.p`
const greet = zt.t`Hello, ${zt.p('name', z.string())}!`
greet.render({ name: 'Alice' }) // → [['Hello, ', '!'], 'Alice']

zt alone is an alias for zt.t:

const same = zt`Hello ${'World'}`

Creates a IRenderable with a Zod object shape that validates all keyword arguments at render time. The shape is passed to z.object(shape).loose(), allowing extra properties for nested composition.

function z<S extends ZodRawShape>(
  shape: S
): TypedTag<input<S>, output<S>>

The returned TypedTag is a tagged template function whose kargs type is the intersection of the shape input and any inline schemas/nested renderables.

const user = zt.z({
  firstName: z.string(),
  lastName: z.string(),
})`Hello, ${e => `${e.firstName} ${e.lastName}`}!`

user.render({ firstName: 'John', lastName: 'Doe' })
// → [['Hello, ', '!'], 'John Doe']

Declares a named keyword argument inline that:

• Wraps the schema in a single-key z.object({ [name]: schema }).
• Decodes the parent kargs to extract kargs[name].
• Applies the optional transform function to produce the final interpolation value.

const tpl = zt.t`Email: ${zt.p('email', z.email(), e => `mailto:${e}`)}`
tpl.render({ email: 'user@test.com' }) // → [['Email: ', ''], 'mailto:user@test.com']

Declares a new IRenderable scoped by the name argument

const button = zt.t`<button>${zt.p('label', z.string())}</button>`
const form = zt.t`Save: ${zt.p('saveBtn', button)} Cancel: ${zt.p('cancelBtn', button)}`
form.render({
  saveBtn: { label: 'Save' },
  cancelBtn: { label: 'Cancel' },
})

The identity IRenderable. Represents a semantically empty structural string. Composes with any IRenderable and leaves it unchanged.

Type: IRenderable<void, []>

const result = zt.t`before ${zt.empty} after`
result.render() // → [['before  after']]

Applies the keyword arguments to a IRenderable returning a new collapsed one.

Returns a new IRenderable that requires no kargs — the provided kargs are validated at bind time and baked in.

Validates at bind time.

const greet = zt.z({ name: z.string() })`Hello, ${e => e.name}!`
const greetAlice = zt.bind(greet, { name: 'Alice' })
greetAlice.render() // → [['Hello, ', '!'], 'Alice']

Lifts an array of raw data into a single composed IRenderable. Each element is transformed via mapFn into the kargs expected by renderable, bound to it, and joined with the optional separator.

const itemTpl = zt.z({ name: z.string(), price: z.number() })`${e => e.name}: $${e => e.price}`
const items = [
  { product: 'Sword', cost: 50 },
  { product: 'Shield', cost: 75 },
]
const list = zt.map(items, itemTpl, item => ({ name: item.product, price: item.cost }), zt.t`, `)
list.render() // → [['', ': $', ', ', ': $', ''], 'Sword', 50, 'Shield', 75]

Joins an array of parameterized values with a structural separator. The functional equivalent of the reduce pattern for building lists of values with structural separators.

const tpl = zt.z({ ids: z.array(z.string()) })`WHERE id IN (${e => zt.join(e.ids, zt.t`, `)})`
tpl.render({ ids: ['a', 'b', 'c'] })
// → [['WHERE id IN (', ', ', ', ', ')'], 'a', 'b', 'c']

Conditionally renders a template. Returns the renderable if the condition is truthy, otherwise returns zt.empty.

Uses JavaScript truthiness, making 0 and '' falsy.

const tpl = zt.z({ name: z.string().optional() })`
  ${e => zt.if(e.name, zt.t`Your name is ${e.name}`)}
`
tpl.render({})          // → [['\n  \n'], ...]
tpl.render({ name: 'A' }) // → [['\n  Your name is ', '\n'], 'A']

Pattern-matching / discriminated union dispatch. Each case is a IRenderable whose shape is extracted, wrapped with a z.literal() discriminator, and combined into a z.discriminatedUnion. At render time, the union validates and routes to the correct branch.

const math = zt.match('op', {
  add: zt.z({ a: z.number(), b: z.number() })`${e => e.a + e.b}`,
  sub: zt.z({ a: z.number(), b: z.number() })`${e => e.a - e.b}`,
  neg: zt.z({ x: z.number() })`${e => -e.x}`,
})

math.render({ op: 'add', a: 10, b: 32 }) // → [['', ''], 42]
math.render({ op: 'neg', x: 5 })          // → [['', ''], -5]
// math.render({ op: 'mul' }) — rejected: 'mul' is not a valid discriminator

Treats a validated value as trusted structure. The value is validated against schema at definition time, then stringified and concatenated directly into the template strings. It never appears in the values array.

Use for identifiers, keywords, or other protocol-level strings that MUST be validated before structural use (column names, sort directions, enum-constrained identifiers).

zt.unsafe injects data into structure, never as values.

const table = 'users' // trusted, not user input
const query = zt.t`SELECT * FROM ${zt.unsafe(z.string().regex(/^\w+$/), table)}`
query.render() // → [['SELECT * FROM users']]

// With validated user-facing enum
const column = z.enum(['id', 'name', 'created_at'])
const tpl = zt.z({ sortCol: column, dir: z.enum(['ASC', 'DESC']) })`
  ORDER BY ${e => zt.unsafe(column, e.sortCol)} ${e => zt.unsafe(z.enum(['ASC', 'DESC']), e.dir)}
`

⚠️ Warning: zt.unsafe concatenates directly into the structure strings. Only use with Zod-validated inputs or hardcoded literals. Never pass raw user input.

Opts a IRenderable out of output tuple type inference. The output is typed as [] (empty), reducing TypeScript compiler pressure for deeply nested kargs or complex compositions of output tuples.

const complex = zt.z({ ... })`... deeply nested with many conditions w/ different sets of values may slow down ts compiler ...`
// If a large template being inserted into a parent one trigger compiler error at parent:
const safe = zt.opaque(complex)
// safe.render(kargs) → IRenderable<..., []> (output tuple hidden from type system)

These utilities transform a rendered interpolation tuple [string[], ...values[]] into a formatted string. They operate on the already-rendered tuple and do not affect the IRenderable itself.

Creates a custom formatter by applying mapFn to each value before calling String.raw. Returns a function that accepts a rendered tuple.

const rendered = zt.z({ x: z.number() })`Value: ${e => e.x}`.render({ x: 42 })
const custom = zt.raw((v, i) => `<${i}>${v}</${i}>`)
custom(rendered) // → 'Value: <0>42</0>'

Formats the interpolation with PostgreSQL-style numbered placeholders ($0, $1, ... $n).

Type: ([string[], ...unknown[]]) => string

const tpl = zt.z({ a: z.string(), b: z.number() })`${e => e.a} = ${e => e.b}`
zt.$n(tpl.render({ a: 'x', b: 1 })) // → '$0 = $1'

Formats the interpolation with @n placeholders (@0, @1, ... @n).

Type: ([string[], ...unknown[]]) => string

zt.atIndex(tpl.render({ a: 'x', b: 1 })) // → '@0 = @1'

Concatenates the interpolation as a raw string for debugging. Equivalent to zt.raw(v => v). Never use in production queries, HTML, or shell commands — this bypasses all parameterization.

Type: ([string[], ...unknown[]]) => string

zt.debug(tpl.render({ a: 'x', b: 1 })) // → 'x = 1'

Type guard. Returns true if v is an IRenderable instance.

if(isRenderable(v)) v.render()

The core interface. A IRenderable is an object with a render method and a RENDERABLE_SYMBOL brand.

Extracts the keyword arguments type from a Renderable:

Extracts the output values tuple type from a Renderable:

Recursively extracts the merged keyword arguments type from a tuple of tagged template interpolation values.

Recursively extracts the merged output values tuple type from a tuple of tagged template interpolation values.

Thrown when validation fails at any level of the interpolation tree. The error includes: Operation type: 'root-schema' | 'karg-schema' | 'renderable' | 'selector' Index: which interpolation hole caused the error Preview: a truncated view of the template around the error site Trace: the chain of nested template calls leading to the error

try {
  myTemplate.render(invalidKargs)
} catch (e) {
  if (e instanceof InterpolationError) {
    console.log(e.message) // Formatted error with preview and trace
    console.log(e.error)   // The original Zod error
  }
}

Either use the zt.t (zod tag template) tag or the schema shape zt.z (zod tag shape) tag to declaratively define you templates, those functions returns a IRenderable interface.

The IRenderable interface provides a render(kargs) method that will receive the keyword arguments (Kargs) in the first parameter as Record<string, unknown> | void (void if no kargs exists for a given template)

When possible unknown will be infered from nested templates, zod schemas input/output or primitives interpolated in the tagged template call.

Interpolate your template with primitive values or no interpolation.

    const greeting = zt.t`Hello`
    // -> IRenderable<void, []>

    const rendered = greeting.render();
    // -> [['Hello']]

    const [strings, ...values] = rendered;
    // strings -> ['Hello']
    // values -> []
    
    const greeting2 = zt.t`Hello ${123}!`.render();
    // strings -> ['Hello ', '!]
    // values -> [123]

Define a shape before you template and interpolate the content with selector functions that manipulates output values from the schema shape.

const greeting = zt.z({
    first: z.string(),
    last: z.string(),
})`Hello, ${e => `${e.first} ${e.last}`}!`


// greeting.render() -> type error and runtime zod validation error

const rendered = greeting.render({
    first: 'John',
    last: 'Doe'
})
// interpolation [strs, ...vals] -> [['Hello, ', '!'], 'John Doe']

Use zt.p to inline named parameters definitions, zod types with object inputs and other renderables also account.

const greeting = zt.t`Hello, ${zt.p('name', z.string())}!`

const rendered = greeting.render({ name: 'John Doe' })
// -> [['Hello, ', '!'], 'John Doe']

const template = zt.t`
    Template heading
    ${zt.p('greeting', greeting)}
`
template.render({ greeting: { name: 'John Doe' }})
// -> [['Template heading\n    Hello, ', '!'], 'John Doe']

Or mix zt.z with zt.p:

const greeting = zt.z({
    date: z.date().optional().default(() => new Date())
})`
    The user ${zt.p('user', z.string())} joined today, ${v => v.date.toLocaleDateString()}}!

`

greeting.render({
    user: 'John Doe',
    date: '01/01/2026', // <- override zod schema w/ .optional()
});
// or greetings.render({ user: 'John' }) given date is optional

Nest your templates and expect the merged kargs, output values and schema validations to just work.

• Works both with namespaced kargs with zt.p or parent scope via zt.z

Due to complex recursive types used to infer the composition kargs, max depth recursion might be reached, so evicting deeply nested templates will avoid slow compilation or recursion limits errors. use zt.opaque(renderable) to complex templates to optout of [...values: Output] tuple inference.

const userHeading = zt.z({ first: z.string(), last: z.string() })`
    First name: ${e => e.first}
    Last name: ${e => e.last}
`

const userFooter = zt.z({ role: z.enum(['Front-End', 'Back-End', 'Full-Stack']) })`
    User role: ${e => e.role}
`

const userCard = zt.t`
    Today: ${new Date().toLocaleDateString()}

    ---- Heading ----
    ${userHeading}

    ---- Footer ----
    ${userFooter}
`

userCard.render({
    first: 'John',
    last: 'Doe',
    role: 'Full-Stack',
})

When the second argument to zt.p is a Zod schema, it creates a validated named parameter.

When it's a renderable, it creates a scoped wrapper, the parent passes { scopeName: { ...childKargs } } and zt.p extracts the nested object before calling the child's .render(). This works recursively, so deeply nested fragments compose cleanly.

const button = zt.t`<button>${zt.p('label', z.string())}</button>`
const addressBlock = zt.z({
  street: z.string(),
  city: z.string(),
})`${e => e.street}, ${e => e.city}`

const form = zt.z({ title: z.string() })`
  <h1>${e => e.title}</h1>
  ${zt.p('saveBtn', button)}
  ${zt.p('cancelBtn', button)}
  Shipping: ${zt.p('shipping', addressBlock)}
  Billing: ${zt.p('billing', addressBlock)}
`

form.render({
  title: 'Checkout',
  saveBtn: { label: 'Place Order' },
  cancelBtn: { label: 'Go Back' },
  shipping: { street: '123 Main', city: 'NYC' },
  billing: { street: '456 Oak', city: 'NYC' },
})

Sometimes we may need to be unsafe just for the sake of sanity (or insanity)

The output of the schema passed as first argument is expected to return a primitive value to be casted into string

const tableName = 'i_promise_this_is_not_user_input';
const greeting = zt.t`SELECT * FROM ${zt.unsafe(z.string().regex(/^\w+$/), tableName)}`
greeting.render(); // -> [['SELECT * FROM i_promise_this_is_not_user_input']]

Values inside the template (TagValue) are expected to be one of the following types:

• IRenderable

Templates can be used as interpolation values, in this case they will be interpolated together and the result is merged in the rendering of the parent template

• Zod schemas

• Object input schemas:

If a zod schema value is expected to receive an object as input the karg shape will be merged in the type definitions and when rendering the template the full karg object will be parsed and the schema output will be used as the actual interpolation value if its primitive, otherwise the output will be processed again.

If its a strict schema and the template has other named arguments this is probably a point of failure.

Note that for zod schemas the zt.p utility is only a an object schema with a single key, an output schema defined in the second parameter and an optional transform fn to determine its output, for nested templates it just scope the parents kargs schema with a namespace key.

• Selector functions ((arg: Karg) => TagValue<Karg>)

A function that receives a single argument with the validated keyword args and returns a primitive or another template value that should be processed again

The whole karg object is received as argument in the selector fn, but only the values in the shape defined with the zt.z tag are already validated and only these are infered by the type system. Kargs defined inline by zt.p or inline object input shapes will be validated only as the interpolation reach the schema value.

• Primitives (or anything else) (string | number | boolean | null | any[] | Record, Date, etc)

Primitive values are left as is, the intention is that after the .render() of a template all values are collapsed into primitives

graph
    zt("Zod Tag (zt)") --> zt.t
    zt --> zt.z
    zt --> zt.p
    zt -->  zt.unsafe

    zt.p -- inline keyword argument definition --> schema --> createRenderable
    zt.p -- scoped nested template --> renderable --> createRenderable
    zt.t -- typed renderable --> typedTag -- validates nested values --> createRenderable
    zt.z -- object shape renderable --> schemaTag -- validates shape and nested values -->