Materials data is structured for documents, not software
Material requirements are commonly communicated through specifications, codes and standards, purchaser requisitions, manuals, and drawings. Evidence then arrives in MTRs, CMTRs, material certificates, heat-treatment records, NDE reports, and other documents. These sources are readable by engineers, but software typically has to rediscover the structure each time.
The result is repeated extraction work, custom parsers for individual document formats, inconsistent field names, duplicated engineering logic, and weak interoperability between engineering, quality, procurement, inspection, and AI systems.
The same material data moves through a lifecycle
A material starts with a governing material or product specification. Application standards and service requirements can add or restrict requirements. A purchaser requisition resolves project-specific choices. The supplier then provides MTR or CMTR evidence, and the material is checked against the effective requirements.
Material specification
+
Application / service requirements
+
Purchaser requisition
↓
Effective material requirements
+
MTR / CMTR / supporting evidence
↓
Material compliance resultMatJSON defines interoperable JSON profiles for the major information objects in that lifecycle instead of forcing every software system to invent its own representation.
A profile for each information object
- MatSpecJSON represents intrinsic requirements of a material or product specification.
- MatReqJSON represents additional requirements imposed by codes, service standards, equipment standards, fabrication practices, and purchaser specifications.
- MatRecordJSON is the planned normalized representation of MTRs, CMTRs, test reports, and other evidence.
- MatCheckJSON is the planned machine-readable record of compliance results and supporting evidence.
- MatJSON Core provides shared units, provenance, identifiers, selectors, expressions, and extension rules.
Explore the MatJSON schema suite →
Software should exchange meaning, not just text
A common materials data schema makes it possible for independently developed systems to exchange the same concepts: chemistry limits, mechanical properties, heat treatment, hardness, impact testing, NDE, product form, traceability, evidence, and requirement provenance. An ERP system, engineering application, inspection platform, supplier portal, API, or analytics service can then communicate using predictable structures rather than organization-specific exports.
This is the core interoperability goal: a material specification JSON file, an MTR JSON record, and a compliance result should be understandable by different software without writing a new parser for every handoff.
Better structure for APIs, automation, and AI
AI can read documents, but repeatable engineering workflows benefit from explicit semantics. Structured data lets software distinguish a requirement from evidence, a maximum from a minimum, a mandatory project invocation from a source recommendation, and a missing requisition input from an MTR failure.
That makes MatJSON useful for material-data APIs, MTR and CMTR parsing, automated compliance checks, procurement workflows, engineering knowledge systems, analytics, and AI agents that need traceable source-aware material data.
An open interoperability layer
MatJSON is intended as an open, vendor-neutral interchange specification rather than a proprietary database. Organizations can keep their own systems, workflows, and licensed standards content while exchanging machine-readable materials data through a shared format.
Initial use cases come from pressure equipment and heat exchangers, but the underlying problem also exists in aerospace, automotive, structural steel, pipelines, nuclear, marine, additive manufacturing, medical devices, electrical conductors, and other material-intensive industries.