# Open3DPP Applied-System Addendum v0.1.0

- **Date:** 2026-07-30
- **Status:** Published public interoperability contract, Apache-2.0, released 2026-08-11 alongside Open3DPP v0.1.0. Not a safety, performance, or conformance certification.
- **Compatibility:** Additive to Open3DPP v0.1.0 and compatible with an unchanged Open3DCP core

## Decision

Open3DPP's flat core record remains the analysis-ready polymer record. This
addendum supplies relational context as linked sidecars rather than adding columns or changing
Open3DCP:

1. **Applied-System Context** records the material stock, equipment/component revision,
   software, planned and actual process, environment, privacy-aware actors, and quality-system
   references.
2. **Measurement and Outcome Bundle** separates measured, predicted, calculated, and reported
   values and connects them to methods, instruments, uncertainty, artifacts, and disposition.
3. **Artifact and Time-Series Manifest** identifies external files by URI and content hash while
   preserving clocks, sensors, calibration, coordinate frames, provenance, and rights.

The schemas describe exchange structure only. They intentionally exclude recommendation
ranking, feature engineering, model weights, confidence thresholds, compatibility rules,
equipment-equivalence maps, and other proprietary decision logic.

## Canonical files

| Sidecar | Draft 2020-12 schema | Example |
|---|---|---|
| Applied system | [`applied-system-context.schema.json`](schemas/addendum/v0.1.0/applied-system-context.schema.json) | [`applied-system-context.example.json`](examples/addendum/applied-system-context.example.json) |
| Measurements/outcome | [`measurement-outcome-bundle.schema.json`](schemas/addendum/v0.1.0/measurement-outcome-bundle.schema.json) | [`measurement-outcome-bundle.example.json`](examples/addendum/measurement-outcome-bundle.example.json) |
| Artifacts/time series | [`artifact-timeseries-manifest.schema.json`](schemas/addendum/v0.1.0/artifact-timeseries-manifest.schema.json) | [`artifact-timeseries-manifest.example.json`](examples/addendum/artifact-timeseries-manifest.example.json) |

Every sidecar has its own stable ID, revision, creation time, provenance, governance, optional
external crosswalks, and namespaced extensions. Sidecars link to an Open3DPP row through
`core_record_ref.record_id`; they may also link to a concrete Open3DCP row without changing that
standard.

## Identity and revision rules

- IDs are opaque and globally unique within the publishing domain. They must not embed a person's
  name, email address, or other unnecessary personal data.
- `revision` identifies the immutable revision of one logical object. A change creates a new
  revision; it does not silently alter a cited record.
- Content-addressed artifacts use lowercase SHA-256.
- Equipment fingerprints declare a version, `SHA-256`, `JCS/RFC8785` canonicalization, the exact
  included field paths, and either `configuration_class` or `private_unit` scope. Direct personal,
  serial, and unit identifiers are excluded from the digest.
- Public records must use a `configuration_class` fingerprint and omit `unit_ref`. Friendly aliases
  and opaque unit references may remain in private records.
- A native slicer profile or `.3mf` file is an artifact referenced from the planned process. It is
  not a substitute for actual machine, material, environment, or outcome context.

## Planned versus actual

`context_kind` is either:

- `specification`: a planned configuration or process; or
- `run`: a realized execution, for which `process.actual` is required.

Planned settings remain distinct from machine/slicer-reported actual settings and operator
interventions. Missing actual values remain missing; they are never copied from the plan.

## Measurement origin

Every result has exactly one `result_origin`:

| Origin | Meaning |
|---|---|
| `measured` | Observed using a cited method and instrument |
| `predicted` | Generated by a versioned model; model internals need not be disclosed |
| `calculated` | Deterministically derived from cited inputs and method |
| `reported` | Transcribed from a cited source without independent measurement |

Predicted values require `prediction_lineage`; measured values require method and instrument
references; reported values require an unambiguous result-level `source_ref`. A prediction does
not become a measurement because it was accepted or later used.

The bundle *references* an external outcome receipt rather than duplicating its contract: the
receipt is identified by its own schema URL and version and is validated by that schema, not by
this one. No particular receipt provider is required. One such receipt schema is the ParaMat3D outcome receipt,
published at `https://paramat3d.com/outcome-receipt.schema.json` (version `1.0.0`); any schema
that identifies itself the same way can be referenced in its place. An optional `outcome_summary` is
a non-canonical index only.

## Equipment, environment, people, and quality context

The applied-system schema covers the quality-system/fishbone inputs without prescribing any
scoring algorithm:

- **Material:** identity, source revision/license, lot or stock, custody, storage, conditioning,
  drying, moisture state, and contamination/reuse state.
- **Machine:** printer/unit revision, controller, extruder, hotend, nozzle, build surface,
  enclosure, material path, sensors, capabilities, calibration, and maintenance references.
- **Method:** base profile, ordered planned and actual steps, settings, overrides, and
  interventions.
- **Measurement:** methods, instruments, calibration, uncertainty, replicates, and decision rule.
- **Environment:** ambient/chamber/material conditions plus linked sensor time series.
- **People:** pseudonymous actor IDs, role, organization, and qualification references; personal
  identity is not required.
- **Design:** geometry/revision, orientation, build layout, and quality objective references.
- **Management/Quality:** FMEA, control plan, deviations, nonconformance/CAPA, approvals, and
  release disposition.

FMEA severity, occurrence, and detectability values may be stored in a controlled referenced
artifact. This contract does not define weights, ranking logic, update rules, or release
thresholds.

## Provenance, rights, consent, and access

Every sidecar is private by default in the examples. Governance separates:

- record visibility (`private`, `team`, `restricted`, or `public`);
- whether public release is explicitly authorized;
- rights status and a license identifier or URI;
- consent for public sharing and model training as independent choices;
- retention and jurisdiction when applicable.

Visibility is a metadata release classification, not an access-control mechanism for referenced
payloads. `visibility: public` is valid if and only if `public_release: true`; both require cleared
rights, a license, and explicit public-sharing consent. Any affirmative sharing or model-training
consent requires a timestamp and basis. Artifact payload access and redistribution remain governed
by each artifact's rights record; a public artifact override requires cleared, licensed,
redistributable rights. Model-training consent is never inferred from public access or service use.

**Licensing.** These schemas are published under **Apache-2.0**, the same licence as the rest of
the repository — see `LICENSE` and `NOTICE`. That grant covers the schemas themselves.

It does **not** extend to the data a record carries. A sidecar describes equipment, environment,
people and artifacts, so an instance may contain personal data, confidential process detail or
third-party material whose rights sit with someone else entirely. Rights over an artifact's
payload are governed by that artifact's own rights record, not by this licence, and permission to
redistribute a schema is not permission to redistribute what someone recorded with it.

A public record should therefore omit or pseudonymize unit serials, people, exact location,
confidential process artifacts, and tenant-private outcomes. An NFC/QR tag should carry a
resolver ID or compact public projection, not a private sidecar.

## Extensions and crosswalks

Vendor/domain additions go under `extensions` using an absolute URI or URN key. Unnamespaced
top-level fields are rejected, preventing collisions with later Open3DPP revisions.

`external_crosswalks` may cite AM-CDM, GEMD, Open3DCP, CPTO/PMDco, Schema.org, or another target.
Each mapping declares source/target versions and hashes where available, plus a mapping class:

- `exact`
- `normalized`
- `derived`
- `partial`
- `sidecar`
- `no_map`

Mappings classified as `partial`, `sidecar`, or `no_map` require an `information_loss` statement.
Crosswalk declarations provide lineage; they are not claims of certification or endorsement.

## Validation

Each sidecar is a Draft 2020-12 JSON Schema and validates with any conforming validator:

```bash
pip install check-jsonschema
check-jsonschema   --schemafile https://open3dpp.org/schemas/addendum/v0.1.0/applied-system-context.schema.json   my-context.json
```

```python
import json, urllib.request, jsonschema

url = ("https://open3dpp.org/schemas/addendum/v0.1.0/"
       "applied-system-context.schema.json")
req = urllib.request.Request(url, headers={"User-Agent": "open3dpp-example/1.0"})
schema = json.load(urllib.request.urlopen(req))
jsonschema.validate(json.load(open("my-context.json")), schema)
```

The worked examples under `examples/addendum/` validate against their schemas and are the
fastest way to see the shape a sidecar takes.

## Change policy

- Additive optional fields may be introduced in a patch/minor revision.
- Renaming, removing, or changing the meaning of a field requires a new major addendum version and
  a migration note.
- The Open3DPP core and Open3DCP are independently versioned; this addendum must never silently
  mutate either.
- Public examples must remain synthetic or explicitly cleared and must not reveal proprietary
  methods or customer data.

**Claim boundary:** These sidecars support traceability and decision support. Material,
equipment, safety, structural, and production decisions require validation appropriate to the
intended use and consequence.