Schemas Try Protos
← Home · Schemas
Schemas define the structure of your engineering data in Protos. Rather than storing artifacts in disconnected spreadsheets or files, schemas give every data type a consistent, queryable shape — reusable across projects and connectable to external tools and integrations.
You don't have to build schemas manually. The Co-Engineer can create them for you — describe what you're working on and it will propose field names, types, and units. See Tutorial: Working with the Co-Engineer.
On This Page
- Use Schemas For
- Creating a Schema
- Field Types
- Using Reference Fields
- Version History
- Bringing External Data into Schemas
- Best Practices
Use Schemas For
- Designs and design parameters
- Test data and experimental conditions
- Model parameterizations and input configurations
- Operating conditions and environmental variables
- Any structured data extracted from external files (SharePoint documents, uploaded PDFs, spreadsheets)
Creating a Schema
For a full step-by-step walkthrough with screenshots, see the Tutorial: Creating Your First Schema.
Quick reference:
- Navigate to Schemas in the left sidebar → New Schema.
- Name it:
[Domain] — [Artifact type](e.g.Battery — Electrolyte Formulation). - Add fields — set type, unit, and whether required.
- Optionally toggle Public to make the schema visible to everyone, not just people you share it with directly.
- Click Save.
Need a variant of an existing schema? Use Clone from a schema's card or row menu in the library instead of starting from scratch.
Tip: Keep schemas lean — only add fields that will actually be populated. A sparse schema with consistent data is far more useful than a dense schema half the team ignores.
Field Types
Each field in a schema is a node with a kind and, for leaf fields, a value type.
Value types (set on a Value node):
| Type | Use for |
|---|---|
string |
Free-form text — labels, notes, identifiers |
number |
Measurable values — always set a unit |
boolean |
Yes / no flags |
enum |
A fixed list of options (e.g. material grade, phase) |
date |
Timestamps for experiments, decisions, imports |
Node kinds determine the structure of the field, not its leaf value. The available kinds are Value, Object (a group of named fields), Array (a list of items of a given kind), Union (a field that can be one of several types), and Ref (a link to another data document). Value types above apply only to Value nodes; ref is a node kind, not a value type.
Using Reference Fields
Reference fields link schemas together, creating a relational structure across your engineering data. This is what makes trace powerful.
Example: A Test Result schema with a reference field pointing to Design Iteration means every test record is traceable to the exact design revision it validated.
To add a reference field:
- In the schema editor, add a new field and set the node kind to Ref.
- Select the target schema.
Note: Use reference fields instead of duplicating data across schemas. Duplication breaks traceability and leads to inconsistencies as designs evolve.
Version History
Every save creates a new, immutable version — open the version-history dropdown in the schema editor header to see the full list, newest first. Open any version to see a summary of what changed from the one before it. From there you can:
- Compare any two versions field-by-field to see exactly what was added, removed, or changed
- Label a version with a short name (e.g. "pre-review baseline") so you can find it again later
- Restore a past version — this creates a new version with the old content rather than deleting anything in between, so the full history stays intact
If this schema references another schema via a Ref field and that schema gets a newer version, an "Update available" banner appears in the editor — click Update to re-pin the reference to the latest version in one step.
See Versioning for the full picture, including how this works across other asset types.
Bringing External Data into Schemas
Protos uses the Co-Engineer to extract data from your existing files and create structured data documents that follow your schema.
How it works
- Define your schema first — the Co-Engineer needs a schema to fill.
- In the Co-Engineer chat, upload a file or pull one in from SharePoint.
- Ask the Co-Engineer to create a data document from it — e.g. "Create an Electrode Formulation document from this test report."
- The Co-Engineer reads the file, maps what it finds to your schema fields, and creates the document. It will flag anything it couldn't find or wasn't sure about.
You review and correct the result before saving.
Supported file sources
| Source | How to bring it in |
|---|---|
| Local file | Upload directly in the Co-Engineer chat (PDF, Excel, TXT) |
| SharePoint / OneDrive | Browse your SharePoint from the Co-Engineer and select a file |
Note: GitHub is not used for data import. GitHub integration in Protos is for registering computational models only — see Model Library.
When to use this
This approach works well when you have existing reports, datasheets, or spreadsheets with values you want to capture as structured data. The Co-Engineer handles the messy extraction; your schema guarantees the result is consistent and comparable with other documents of the same type.
Best Practices
- Standardize units before creating numeric fields — changing units later requires a data migration.
- Name schemas by domain + artifact type for discoverability across the workspace.
- Use version history for structural changes — compare, label, or restore a past version if a change breaks existing data.
- Agree on a reference field convention with your team before building out multiple related schemas.
See Also
- Model Library — model input/output schemas follow the same conventions
- Simulation Studio — pull schema values directly as simulation inputs
- Knowledge Library — promote schema entries to reusable knowledge assets
- Glossary → Reference field