---
title: CEDAR Templates in Data Science & Policy
url: https://www.emergentmind.com/topics/cedar-templates
type: topic
---

# CEDAR Templates in Data Science & Policy

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 [2601.06606]. In the CEDAR metadata ecosystem, they are machine-actionable specifications of community metadata standards, represented structurally in JSON Schema and instantiated as JSON-LD [1905.06480]. In the Cedar authorization language, templates are policies with named slots such as `?principal` and `?resource` that are later linked to concrete entities [2403.04651].

## 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 | [2601.06606] |
| FAIR metadata | Machine-actionable metadata schema | [2208.02836] |
| Authorization policy | Policy with named scope slots | [2403.04651] |

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 [2507.22391]. In the authorization literature, templates are scoped Cedar policies that can be instantiated repeatedly without changing the evaluation model [2403.04651]. In the agentic data-science literature, templates standardize how a problem is described, decomposed, and carried forward through an interleaved text-and-code history [2601.06606].

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 [1011.0715]. CEDAR-42001 uses “templates” to denote row and table structures for architecture-aware ISO/IEC 42001 audit analysis [2606.21276]. 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 [2601.06606]. 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 [2601.06606].

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 [2601.06606].

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 [2601.06606].

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 [2601.06606].

## 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 [2208.02836]. 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 [1905.06480]. 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` [2208.02836].

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 [2508.00859]. 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 [2507.22391].

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 [1905.06480]. 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 [2508.00859]. The same template can therefore govern web forms, spreadsheets, embedded editors, validators, and repository ingestion workflows [2507.22391].

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 [2208.02836]. 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)\) [2208.02836].

## 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 [2403.04651]. 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
```cedar
permit(Principal, Action, Resource) [when { ... }] [unless { ... }];
forbid(Principal, Action, Resource) [when { ... }] [unless { ... }];
```
and evaluation follows a default-deny, forbid-overrides semantics [2403.04651]. 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)\) [2403.04651].

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 [2403.04651]. 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 [2403.04651].

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 [2607.03656]. 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 [2607.03656].

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 [2606.26649]. 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 [2601.06606]. In CEDAR metadata systems, templates generate forms, constrain inputs, drive ontology lookup, produce JSON-LD, and anchor validation and repository submission [1905.06480]. In Cedar authorization, templates compile into ordinary policies that participate in real-time authorization decisions [2403.04651].

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 [2208.02836]. 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 \(p < 0.01\), with \(d > 0.8\) for GPT-4+CEDAR versus baseline [2504.05307]. The central mechanism is “template-augmented prompt engineering,” in which field names, descriptions, and constraints are injected directly into the prompt [2504.05307].

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 [2607.03656]. 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 [2606.26649].

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 [2208.02836]. FAIRware can introduce incorrect repairs, which is why corrected metadata are stored separately rather than overwriting originals [2208.02836]. 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 [2508.00859].

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 [2607.03656]. 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 [2606.26649].

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 [2601.06606]. 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 [2507.22391]. Authorization templates are safest when backed by schemas, validators, and symbolic analysis [2403.04651]. Agentic templates rely on stable contracts between orchestrators, sub-agents, and local execution environments [2601.06606]. 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.

Source: https://www.emergentmind.com/topics/cedar-templates