CEDAR Templates in Data Science & Policy

Updated 7 July 2026

CEDAR Templates are structured, reusable artifacts that standardize multi-agent data science workflows, metadata schemas, and policy settings.
They automate complex processes by integrating prompt design, plan-code interleaving, and dynamic history rendering in data science systems.
They enable machine-actionable metadata specifications and real-time policy instantiation, ensuring rigorous validation and operational consistency.

CEDAR Templates denotes several distinct template systems that share a common concern with structured specification. In the CEDAR agentic data science system, templates are prompt, orchestration, and history-rendering patterns for multi-agent data-science workflows (Roy et al., 10 Jan 2026). In the CEDAR metadata ecosystem, they are machine-actionable specifications of community metadata standards, represented structurally in JSON Schema and instantiated as JSON-LD (Gonçalves et al., 2019). In the Cedar authorization language, templates are policies with named slots such as ?principal and ?resource that are later linked to concrete entities (Cutler et al., 2024).

1. Terminological scope and disambiguation

The term is not tied to a single software stack or research problem. It appears in at least three major lineages, each using “template” to mean a reusable, constrained artifact that can be rendered, validated, instantiated, or executed.

Research lineage	Meaning of “template”	Representative source
Agentic data science	Structured prompt and workflow patterns	(Roy et al., 10 Jan 2026)
FAIR metadata	Machine-actionable metadata schema	(Musen et al., 2022)
Authorization policy	Policy with named scope slots	(Cutler et al., 2024)

In the metadata literature, templates are explicitly treated as formal encodings of community reporting standards and, in later work, as declarative knowledge bases for open science (Musen et al., 30 Jul 2025). In the authorization literature, templates are scoped Cedar policies that can be instantiated repeatedly without changing the evaluation model (Cutler et al., 2024). In the agentic data-science literature, templates standardize how a problem is described, decomposed, and carried forward through an interleaved text-and-code history (Roy et al., 10 Jan 2026).

The acronym also appears in unrelated literatures. HTCondor’s CEDAR is a secure communication library whose reusable “templates” are architectural patterns around authentication, session management, and delegation rather than metadata or policy artifacts (Miller et al., 2010). CEDAR-42001 uses “templates” to denote row and table structures for architecture-aware ISO/IEC 42001 audit analysis (Surve et al., 19 Jun 2026). This suggests that “CEDAR Templates” is best understood as a family of domain-specific structuring devices rather than a single formal object.

2. Agentic data-science templates

In CEDAR, expanded as “Context Engineering for Data science with Agent Routing,” templates are a family of structured prompt and workflow patterns designed to turn a loosely specified data-science task into a multi-step agentic process (Roy et al., 10 Jan 2026). The first layer is a structured input form. General instructions include the estimated number of solution steps, expected number of plots, verbosity of plans, and related global controls. Task-specific instructions include Task description, Data description, Data location, Metrics, Inputs, Outputs, and Special instructions. These fields are rendered into a shared “project summary” visible to all agents.

The second layer is the orchestrator schema. CEDAR uses three LLM agents: an orchestrator agent, a text agent, and a code agent. The orchestrator receives the project summary and rendered history and emits a structured JSON action with one of three forms: request_text, request_code, or finish. The key arguments are spec for narrative scope and purpose for operational goal. This routing schema separates decision-making from content generation and is described as reducing hallucinated tool names and parsing errors (Roy et al., 10 Jan 2026).

The third layer is the canonical workflow structure. CEDAR materializes a solution as an enumerated sequence of interleaved Markdown plan blocks and Python code blocks, analogous to a notebook. In formal shorthand, a workflow can be written as

$(\text{Text}_1, \text{Code}_1, \text{Text}_2, \text{Code}_2, \dots, \text{Text}_T, \text{Code}_T).$

Each plan block explains the next step; each code block implements it. The paper presents this pattern as a readable context structure that remains inspectable at any step of the workflow (Roy et al., 10 Jan 2026).

The fourth layer is history rendering. The renderer appends the project summary, numbers prior blocks as Text #k or Code #k, keeps full text and code for successful steps, includes only heads of outputs, and includes only the tail of the traceback for the latest failed code block. If the history exceeds a default character budget of $10^4$ , it is truncated to the most recent 10k characters. Code is executed immediately in a Docker container, and failed code can be retried with the previous code, the tail of the traceback, and the same or refined purpose; the default maximum number of code retries is 3 (Roy et al., 10 Jan 2026).

These templates are therefore not merely prompt fragments. They include the form-based problem description, the orchestrator’s JSON action schema, the plan–code alternation, and the deterministic history template that decides what survives into later prompts. The system’s local-first design further constrains template use: data remain local, while only aggregate statistics and associated instructions are injected into LLM prompts (Roy et al., 10 Jan 2026).

3. Metadata templates in the CEDAR ecosystem

In the metadata line of work, CEDAR templates are machine-actionable, structured specifications of metadata that encode what a scientific community considers the minimum, rich, domain-relevant description of a dataset or experiment (Musen et al., 2022). They are the computable counterpart of prose reporting guidelines such as MIAME, MIATA, or CONSORT. A template names fields, assigns data types, marks fields as required or optional, constrains values through enumerations or ontologies, assigns unique identifiers, and organizes fields into reusable template elements.

The core data model is compositional. A template contains template elements and fields; template elements may themselves contain other elements and fields; fields are atomic metadata attributes with names, value types, and constraints (Gonçalves et al., 2019). CEDAR represents templates using JSON Schema and represents filled-in metadata instances as JSON-LD, so that structure and semantics are both machine-processable. Controlled values are often stored as ontology URIs plus human-readable labels, and primitive values can carry explicit XSD types such as xsd:float (Musen et al., 2022).

Ontology assistance is central. The Workbench integrates with NCBO BioPortal for ontology lookup, value restrictions, and controlled term selection, and later deployments add external authority resolution for persistent identifiers such as ORCID and ROR through the CEDAR Embeddable Editor (O'Connor et al., 16 Jul 2025). The result is not only structured metadata but semantically grounded metadata, in which values can be tied to ontologies, value sets, RRIDs, ORCIDs, or ROR identifiers (Musen et al., 30 Jul 2025).

These templates are used operationally across a broad infrastructure. The CEDAR Workbench provides a Template Designer, Metadata Editor, Resource Manager, REST APIs, ontology services, value recommendation, validation, and submission to external repositories (Gonçalves et al., 2019). The CEDAR Embeddable Editor is a Web Component that renders forms directly from templates and returns JSON-LD, enabling “author once, publish everywhere” deployment in third-party platforms such as the Open Science Framework and Dryad (O'Connor et al., 16 Jul 2025). The same template can therefore govern web forms, spreadsheets, embedded editors, validators, and repository ingestion workflows (Musen et al., 30 Jul 2025).

The FAIR interpretation of templates is explicit. “Rich” and “domain-relevant” metadata are not inferred by repositories; they are encoded directly by communities in templates (Musen et al., 2022). FAIRware evaluates archived metadata against such templates using two summary notions: completeness, based on presence of required fields, and adherence, based on datatype and ontology compliance. The underlying logic is template-relative: if $R(T)$ is the set of required fields in template $T$ and $F(M)$ is the set of fields present in metadata record $M$ , completeness is high when $R(T) \subseteq F(M)$ (Musen et al., 2022).

4. Authorization and policy-as-code templates

In Cedar, the authorization language, a template is a policy that contains named slots rather than concrete entities (Cutler et al., 2024). The currently supported slots are ?principal and ?resource, and they are allowed only in scope, not in when or unless. A template therefore resembles a prepared statement: it defines the shape of access, and later linking fills in concrete entity IDs to produce an ordinary permit or forbid policy.

This design sits inside a broader authorization model with principals, resources, actions, context, and an entity store. Policies take forms such as $10^4$ 2 and evaluation follows a default-deny, forbid-overrides semantics (Cutler et al., 2024). Because template parameters appear in scope, instantiated policies remain compatible with Cedar’s indexing and policy slicing mechanisms. The paper formalizes this with keys based on the principal and resource part of scope, so that relevant policies can be found quickly for a request $(P,R)$ (Cutler et al., 2024).

Several recurring template patterns are documented. GitHub-style repository permissions are expressed as per-repository templates such as readTemplate, writeTemplate, or adminTemplate; Google Drive–style sharing is expressed as a read-access template over ?principal and ?resource; TinyTodo-style sharing can be moved from attribute-based ACLs to template-instantiated policies; and forbid templates support per-object locks or guardrails (Cutler et al., 2024). The design advice is correspondingly narrow: put principal and resource selection in scope, keep actions specific, and use static policies for global invariants such as owner rights or office-hours constraints (Cutler et al., 2024).

Recent work treats such templates as synthesis targets. AutoCedar decomposes natural-language access-control requirements into schema atoms and property atoms, then compiles them into a Cedar schema $\Sigma$ and a boundary plan $\Pi = (\mathcal{F}, \mathcal{C}, \mathcal{G})$ consisting of floors, ceilings, and liveness slices (Vatsa et al., 4 Jul 2026). Candidate policy bundles are checked mechanically, and failures are turned into repair directions: tighten, loosen, expand, or local. AutoCedar converges on all 221 tasks of CedarBench and reports fully passing property and semantic-request checks for healthcare, education, and conference-management case studies (Vatsa et al., 4 Jul 2026).

A related line autoformalizes agent instructions, MCP tool descriptions, and natural-language policies into Cedar policies. The pipeline generates a Cedar schema programmatically from tool definitions, uses an LLM generator to propose policies, applies a hard critic through the cedar-policy CLI for syntax, schema compliance, and logical contradictions, and uses a soft critic for semantic alignment (Mondl et al., 25 Jun 2026). The output is an auditable policy store enforced outside the agent’s prompt context.

5. Templates as executable infrastructure

Across these literatures, templates are not passive documentation. They are executable or operational artifacts. In CEDAR agentic data science, templates determine what is rendered into prompts, what JSON actions are legal, how notebook-like plans and code are interleaved, how errors are summarized, and how retries are issued (Roy et al., 10 Jan 2026). In CEDAR metadata systems, templates generate forms, constrain inputs, drive ontology lookup, produce JSON-LD, and anchor validation and repository submission (Gonçalves et al., 2019). In Cedar authorization, templates compile into ordinary policies that participate in real-time authorization decisions (Cutler et al., 2024).

The evaluation literature makes this operational role explicit. FAIRware uses templates to inspect metadata for missing required fields, datatype mismatches, ontology violations, and repair candidates (Musen et al., 2022). AI-driven metadata standardization uses CEDAR templates as symbolic guidance for GPT-4. In BioSample and GEO, GPT-4+CEDAR raises average recall from 17.65% with baseline raw metadata to 62.87%, with BioSample recall moving from 20% to 82% and GEO recall from 15% to 44%; precision rises from 58% to 66%, F1-score from 24% to 63%, and paired t-tests are reported as statistically significant with $10^4$ 0, with $10^4$ 1 for GPT-4+CEDAR versus baseline (Sundaram et al., 13 Feb 2025). The central mechanism is “template-augmented prompt engineering,” in which field names, descriptions, and constraints are injected directly into the prompt (Sundaram et al., 13 Feb 2025).

In policy systems, the same executable character appears differently. AutoCedar’s schemas and boundary plans are reviewed targets against which synthesized policies are verified, while the MedAgentBench autoformalization pipeline uses Cedar policies as a runtime gate for tool calls (Vatsa et al., 4 Jul 2026). In the latter, Cedar achieves near-complete coverage for trajectories with POST writes: block rates are reported as 100.0% for several experimental conditions and 98.8% in the original Guardrail condition (Mondl et al., 25 Jun 2026).

This convergence on executable use is one of the defining properties of the term. A CEDAR template is typically a constraint-bearing artifact that software can consume directly rather than a prose guideline that humans must interpret informally.

6. Limitations, governance, and future directions

The literature also emphasizes the costs and limits of templating. In the metadata domain, communities must invest substantial effort to agree on required fields, ontologies, and levels of detail; overly ambitious templates can burden investigators, and evolving practices require versioning and governance (Musen et al., 2022). FAIRware can introduce incorrect repairs, which is why corrected metadata are stored separately rather than overwriting originals (Musen et al., 2022). The CEDAR Embeddable Editor currently lacks advanced dynamic branching and complex cross-field validation, and work is ongoing on spreadsheet round-tripping and extraction of metadata from primary data sources (O'Connor et al., 16 Jul 2025).

In authorization, guarantees are only as good as the reviewed intent. AutoCedar explicitly depends on human review of intent atoms, must handle incompatible floor/ceiling combinations, and is limited by what Cedar can express; quantitative rate limits or dynamic obligations may require compilation into finite verifier obligations rather than direct runtime policy (Vatsa et al., 4 Jul 2026). The agent-policy autoformalization pipeline similarly notes omission risk, over-restriction, and Cedar’s statelessness for sequence-sensitive behaviors, motivating future integration with temporal logic and memory-aware monitors (Mondl et al., 25 Jun 2026).

The agentic data-science system frames its own problem as one of task complexity, data size, computational limitation, and context restriction, and addresses these through structured prompts, history budgeting, and iterative code repair rather than by removing the constraints themselves (Roy et al., 10 Jan 2026). This suggests that, in that setting, templates are primarily a context-management strategy.

A persistent theme across all lineages is governance. Metadata templates are community-curated research objects, often developed through consortial working groups or Metadata for Machines workshops (Musen et al., 30 Jul 2025). Authorization templates are safest when backed by schemas, validators, and symbolic analysis (Cutler et al., 2024). Agentic templates rely on stable contracts between orchestrators, sub-agents, and local execution environments (Roy et al., 10 Jan 2026). In each case, the template is valuable not because it is abstract, but because it externalizes a community’s operational standard in a form that can be reused, audited, and enforced.