SUM is a desktop application an archaeologist runs on the trench edge: it captures US sheets, builds the Harris/Extended Matrix from them automatically, and exports the result — and it already speaks Extended Matrix at the export boundary, because its matrix is written through the s3dgraphy/Stratigraphy exporter and opens directly in the official EM 1.6 yEd palette. It was built from scratch by Mattia Curto as a specialisation-school thesis, re-architected from an earlier monolith into a clean MVC application (configurable forms over an SQLite core, a plugin loader resolved at startup, a multilingual UI, an embedded Python console) and packaged as a standalone executable. It is GPL by deliberate choice.
What earns SUM a DP is the gap it fills. PyArchInit gives the field the 2D drawing and the GIS but has no graph viewer; EM Tools gives the graph authoring environment but no field data-entry surface. SUM is vertical on exactly the missing piece — fast, low-friction stratigraphic data capture that produces an EM-native matrix. The entry model is built for a tired operator: type a US code, hit Enter, double-click to flip a relation; the temporal above/below is captured automatically and the matrix redraws itself, with layout-optimisation, repair and diagnostics buttons to keep it clean. Marking a sheet as a virtual US (via the SAD Stratigraphy plugin) pulls in the extended palette, so the tool sits inside the EM ecosystem rather than beside it. For the archaeologist this is a gentle on-ramp to Extended Matrix — they meet a familiar ICCD sheet and a readable matrix, not an unfamiliar formalism dropped on them cold.
The reason it is embargoed rather than published: this is an unpublished thesis (Curto, expected 2027), and the embargo protects the candidate’s academic priority until it is defended/published — the same convention used for DP-01 and DP-16. The embargo is not a statement about technical maturity (that is what status: in-dev records); it is a publication-priority hold. Authorship stays with Curto; the EM ecosystem is the interoperability host, not the owner.
The path from EM-compatible on export to fully EM-interoperable is a short, known list, because the StratiGraph project already worked these requirements out for field tools. First, the resident format: SUM today thinks tabular and only emits EM when it exports; the target is to keep an in-memory s3dgraphy property graph as the resident model (or at least a canonical EM interchange file underneath), so the UI lists are projected from the graph at runtime, schemaless. That single shift is what lets the same data render as an Italian, German or French ministerial sheet through a clean per-schema JSON mapping, and it is the European data-sovereignty argument made concrete — the tool stops being welded to one national schema. Second, the mapping JSON: a one-time, hand-editable file that maps each DB column to an existing EM node type (precisely what the s3dgraphy pandas → graph path consumes); SUM could even ship the mapping editor and share the artefact with EM Tools, which is where DP-61 meets it. Third, bidirectional interchange rather than one-way export, so SUM ↔ EM Tools ↔ PyArchInit all ride the same graph formalism and link directly — DP-62’s canonical-edges round-trip is the reference implementation. Fourth, a dynamic UI generated from a JSON configurator, so the data-entry interface follows the schema descriptor instead of being hard-coded to ICCD.
Nearer-term, the meeting produced a concrete punch-list: after a temporal relation is entered, auto-propose every compatible physical relation (prefilled red, the operator confirms one and the rest die) so physical stratigraphy becomes as fast as temporal; swap the ‘find errors’ icon for a stethoscope and add a plaster icon for ‘repair’, grouped by export; move confirmation pop-ups out of modals into a footer status line so they never block the view; rework the obsolete finds section; and remove the early raw GraphML/PNG export that pre-dated the s3dgraphy exporter and now only causes confusion. In parallel, bumping the bundled s3dgraphy to the 1.6 dev build lets physical relations be packed into the per-node GraphML custom field and survive the export — the same mechanism DP-62 formalises. The agreed next steps are an SRS (the requirements analysis that should anchor the thesis and the build), an appearance at the EM developer hour, and — if Curto wishes — publishing the GPL repository to the community so contributions arrive as PRs and issues. Origin of this DP: the meeting of 2026-06-11.
1.7
Needed — thesis case study in preparation (Curto, expected 2027); already used experimentally on a live excavation.
Origin: meeting Demetrescu × Curto, 2026-06-11. Internal launch build nicknamed 'Montepelmo'. Author: Mattia Curto (Scuola di Specializzazione, 2nd year, runway to 2027); not on staff — a field practitioner with a research bent. Licence: GNU GPL (chosen deliberately to keep the project open and attract community PRs). // INTEROPERABILITY ROADMAP (the StratiGraph field-tool requirements that move SUM from 'EM-compatible on export' to 'EM-interoperable'): (1) RESIDENT FORMAT — today SUM thinks tabular (SQLite under the hood) and only emits EM on export. Target: keep an in-memory s3dgraphy property graph as the resident model (or at minimum a canonical EM interchange file — tabular EM / GraphML / pure s3dgraphy JSON — underneath), so UI lists are projected from the graph at runtime, schemaless, no metadata schema fixed up front. This is what lets the same data render as an Italian, German or French sheet via a clean per-schema JSON mapping. (2) MAPPING JSON — one-time, hand-editable JSON that maps each DB column to an existing EM node type (the s3dgraphy `pandas → graph` path takes exactly this). SUM could ship a mapping *editor* (author the JSON once, reuse it in EM Tools too) — converges with DP-61. (3) BIDIRECTIONAL INTERCHANGE — not just GraphML export but round-trip, so SUM ↔ EM Tools (Blender) ↔ PyArchInit all share one graph formalism and link directly; the canonical-edges work in DP-62 is the reference. (4) DYNAMIC UI FROM A JSON CONFIGURATOR — generate the data-entry interface from a schema descriptor so SUM serves ICCD, the Austrian model, French and other EU ministerial schemas without code changes (Curto: 'impegnativo ma interessante'). EU data-sovereignty angle: the schemaless graph is what keeps the tool from being locked to one national schema. // SHORTER-TERM ACTION ITEMS from the meeting: auto-propose all compatible physical relations after a temporal relation is entered (prefill them red, user picks the right one, the rest die); replace the 'find errors' icon with a stethoscope and add a plaster/bandage icon for 'repair', both grouped near export; move confirmation pop-ups from modals to a footer status line; rework the obsolete finds section; drop the early raw GraphML/PNG export that pre-dated the s3dgraphy exporter (confusing duplicate). // NEXT STEPS: Curto to (a) write the SRS, (b) attend the EM developer hour, (c) consider publishing the GPL repo to the community; bump bundled s3dgraphy to the 1.6 dev build (≥ the build that packs physical relations into the per-node GraphML custom field) so physical relations survive export. // Cross-refs: DP-62 (PyArchInit ↔ s3dgraphy canonical-edges round-trip — the interoperability reference), DP-61 (EM Mappings Registry & Builder — where the mapping JSON belongs), DP-64 (viewport stratigraphic annotator — sibling field-annotation surface), DP-41 (swimlane epoch-local data — the tabulation problem), DP-55 (SU creation workflow unification), DP-51/DP-59 (author node / ORCID identity).