Skip to content
Crosswalker
🚧 Early alpha — building the foundation. See the roadmap →

Evidence-link edge model synthesis — junction notes as the committed architecture

Created

Why this log exists

Section titled “Why this log exists”

On the morning of 2026-04-10 the main Foundation research synthesis landed — distilling 4 parallel research sessions against the Foundation-phase decisions. That synthesis committed Crosswalker to STRM + SSSOM for ontology-to-ontology crosswalks, but explicitly scoped out evidence-link edges — the MFA-Policy.md → NIST 800-53/AC-2 case with status, reviewer, review_date, and sufficient: true kind of metadata. That scope note sat as an acknowledged gap in the synthesis log’s :::caution callout, pointing forward to a separate Foundation decision.

Challenge 07 was spun out as a fresh-agent research brief to resolve that gap. The same afternoon, two research sessions landed in .workspace/ targeting it directly:

  1. Claude-Link metadata edge model research challenge.md (21KB) — the primary response, structured as a direct answer to Challenge 07’s four success criteria (storage shape, field schema, workflow model, OSCAL round-trip)
  2. Claude-Graph to tabular ontology linking in knowledge tools.md (28KB) — a broader PKM comparative research covering how every major knowledge-management tool (Obsidian, Roam, Tana, Notion, Capacities, AnyType, Heptabase) handles — or fails to handle — edge metadata

Both files independently converge on the same architecture. This log distills the convergence, reproduces the proposed schema verbatim for archival quoting, and proposes committing the direction as a Foundation decision — with a clear list of which sub-questions are decided now and which are still open design calls downstream.

What we tested against

Section titled “What we tested against”

The Foundation decisions under review for evidence links specifically:

  • The Evidence link vs Crosswalk distinction — the two edge categories terminologically separated in the morning synthesis
  • The stale link metadata system design — Crosswalker’s original motivation, which proposed inline Dataview syntax (framework_here.applies_to:: [[AC-2]] {JSON}) and a 5-level priority hierarchy
  • The Obsidian Bases commitment — our committed viewing/query layer, which replaces Dataview and has specific known constraints (flat YAML only, no nested objects, no arrays of objects, no inline-field parsing)
  • The Progressive tier architecture pillar — files-canonical at Tier 1, sql.js WASM sidecar at Tier 2, server-backed at Tier 3
  • The 04-10 synthesis commitment to STRM + SSSOM for crosswalks — which the evidence-link decision must coexist with
  • The roadmap item “Evidence-framework edge model” — currently marked “decision needed, anticipated direction: custom Crosswalker-specific schema building on original link metadata syntax + borrowing OSCAL Implementation Layer concepts”

The two research files

Section titled “The two research files”

File 1 — Claude-Link metadata edge model research challenge.md (21KB)

Section titled “File 1 — Claude-Link metadata edge model research challenge.md (21KB)”

Thesis: “The only architecture that gives Obsidian Bases full queryability over evidence-to-control link metadata is the ‘edge-as-note’ pattern — a dedicated markdown file per evidence-control relationship.” The file is a direct answer to Challenge 07 with a proposed 13-field schema, a full OSCAL by-component mapping, a three-dimensional status vocabulary (implementation status + freshness + evidence type), git-based audit trail with 3 hardening measures, SSSOM-inspired dual-confidence scoring, and file-proliferation mitigations. Validated against 8 commercial GRC tools and 4 open-source frameworks (OSCAL, OpenControl, Drata, Hyperproof, Auditree, AuditBoard, Anecdotes, ISO 27001 SoA, SOC 2, CMMC, InSpec, Kosli).

Strongest claim: “Obsidian Bases queries exclusively YAML frontmatter properties… Nested YAML objects render as type ‘unknown’ and are unqueryable; a 281-vote feature request for nested YAML support remains unaddressed. Arrays of objects are entirely unsupported.” This constraint eliminates 3 of the 4 architectures Challenge 07 listed; junction notes emerge as a 5th option the research adds.

File 2 — Claude-Graph to tabular ontology linking in knowledge tools.md (28KB)

Section titled “File 2 — Claude-Graph to tabular ontology linking in knowledge tools.md (28KB)”

Thesis: “No mainstream PKM tool natively supports metadata on relationships between notes — and this single gap is the central architectural challenge behind the Crosswalker project.” The file takes a broader comparative angle, surveying how every major PKM tool handles edge metadata, documenting the academic reification literature (Chris Mungall’s RDF reification series, RDF-star/SPARQL-star, Meta-Property Graphs EDBT 2025), comparing Obsidian Bases’ limitations against Dataview, documenting junction note scalability debt at thousands of files, and flagging Obsidian’s filename-based linking as fundamentally fragile across out-of-app file moves.

Strongest claim: “The ideal solution would combine Tana’s semantic type system, Obsidian’s file portability, Bases’ performance, and property graph edge attributes. RDF-star’s compact reification syntax points toward what this could look like in practice. Until a tool achieves this synthesis, every PKM practitioner working with relationship-heavy knowledge will continue paying the tax of workarounds.” Junction notes are one such workaround — and for the Obsidian+Bases constraint specifically, they’re the least-bad one.

Convergences — where both files independently agree

Section titled “Convergences — where both files independently agree”

1. Junction notes are the only viable architecture for Obsidian Bases

Section titled “1. Junction notes are the only viable architecture for Obsidian Bases”

Both files independently recommend reifying each evidence→control edge as its own markdown file. File 1 derives the conclusion from direct analysis of Bases’ YAML constraints; File 2 validates it against comparative PKM research showing that every tool-community has independently reached the same workaround when native edge metadata isn’t available. The two independent derivations are the strongest signal in the entire research set.

File 2 also traces the idea to etothepiiminus1’s April 2021 “Edge Notes” post on the Obsidian Forum — a never-built plugin proposal that would auto-create “AB” notes when a link between A and B was labeled “node-worthy,” forming clickable triangles in graph view. The community has been circling junction notes as the solution for five years; File 1’s contribution is the concrete schema.

2. Reification is the academic foundation

Section titled “2. Reification is the academic foundation”

Both files ground junction notes in reification — the formal knowledge-representation pattern of making a statement about a statement by turning the statement into a node. File 2 explicitly cites Chris Mungall’s “Edge properties, part 1: Reification” blog series (Berkeley Lab, September 2020) as the canonical inventory of approaches: standard RDF reification (verbose, 6+ triples per edge), n-ary relations (the junction note pattern), named graphs (4th element as attachment point), and RDF-star/SPARQL-star (compact inline syntax). File 1 implicitly uses reification throughout without naming it.

The 2025 EDBT paper “Meta-Property Graphs: Extending Property Graphs with Metadata Awareness and Reification” (arXiv:2410.13813) and Hamdani & Türkarslan’s Springer 2026 “Bridging Property Graphs and Knowledge Graphs: A Category Theory Approach” formalize the same gap at the academic level. Junction notes are the pragmatic PKM implementation of what formal graph theory has studied for decades.

3. OSCAL by-component is the export target

Section titled “3. OSCAL by-component is the export target”

Both files converge on mapping the edge model to OSCAL’s by-component assembly in the System Security Plan (SSP) model. File 1 produces a full field-by-field mapping table (reproduced below in OSCAL round-trip); File 2 mentions OSCAL as background without detail. The consensus direction: the junction note schema should be isomorphic to by-component so round-trip conversion is mechanical, not interpretive.

4. Git history is the native audit trail

Section titled “4. Git history is the native audit trail”

Both files use git commit history as the audit mechanism for edge changes. File 1 adds three specific hardening measures (signed commits, branch protection, periodic snapshots to an append-only external store) and cites Kosli (backed by Deutsche Bank) and Auditree as production-grade compliance-as-code platforms that use git repositories as evidence stores with Merkle-tree tamper-evidence. File 2 flags git’s mutability risk (commit --amend, rebase, force-push) without proposing solutions.

Both acknowledge git’s one structural limitation: git tracks writes but not reads — there’s no access log for who viewed the vault, only who changed it. For local-first scenarios this is acceptable; for enterprise multi-user deployments a platform-level audit log (GitHub Enterprise, GitLab audit events) would supplement git history.

5. Flat YAML is the constraint that forces the entire design

Section titled “5. Flat YAML is the constraint that forces the entire design”

Both files identify Obsidian Bases’ lack of nested property support as the hard constraint driving every other decision. Bases’ YAML frontmatter engine supports: text, number, checkbox, date, datetime, and flat lists. It does not support: nested YAML objects (feature request at 281 votes, still unaddressed), arrays of objects, relation property types, nested tags (file.hasTags("project") does not match project/english), or note-body content querying.

These constraints eliminate the three storage shapes from Challenge 07’s list — inline markdown body, frontmatter arrays of objects, sidecar files — and push any workable architecture toward either junction notes or a hybrid that sacrifices Bases queryability for some subset of the data. Junction notes win because they’re the only option where 100% of the edge metadata is natively Bases-queryable.

6. File proliferation is a known tradeoff — and it’s manageable

Section titled “6. File proliferation is a known tradeoff — and it’s manageable”

Both files acknowledge that thousands of junction notes create folder clutter, search pollution, and navigation overhead. File 1 mitigates this with four patterns: (1) Templater automation for junction creation via hotkey, (2) Bases views as the primary interface rather than direct file browsing, (3) denormalized rollup properties on evidence and control notes, (4) folder-based assessment scoping (links/2026-Q1-assessment/). File 2 documents the problem in more detail but doesn’t propose mitigations.

File 2 flags Obsidian’s performance cliffs at extreme scale: 4-second link-autocomplete delays at very large vaults, graph view becomes unusable beyond ~6,000 densely linked notes. File 1 proposes “thousands of junction notes” without testing data, leaving the exact scalability threshold as an open sub-question.

Divergences — the 5 points of disagreement

Section titled “Divergences — the 5 points of disagreement”

1. UUID resilience urgency

Section titled “1. UUID resilience urgency”

File 2 emphasizes Obsidian’s filename-based linking as “fundamentally fragile” when files move outside the app (via terminal, scripts, git operations, file explorer). Links break silently. File 2 quotes the Obsidian developers directly: “There will be cases where outside Obsidian you can break the internal consistency. There is nothing we can do about it.” File 2 proposes UUID-based strategies (Unique Identifiers plugin, Link by ID plugin, obsidian-note-uid) as resilience mechanisms.

File 1 does not address this at all. It assumes filenames are stable and ignores out-of-app file moves. Open sub-question: Is UUID-based resilience a Foundation-phase requirement, or a Tier 2/3 concern that the file-based tier can safely defer? The obsidian-folder-tag-sync + SEACOW prior-art log touches on resilience across file moves — may deserve a dedicated decision.

2. SSSOM integration scope

Section titled “2. SSSOM integration scope”

File 1 explicitly proposes borrowing three SSSOM concepts: dual-confidence scoring (creator + reviewer agreement), mapping justification vocabulary (compliance-extended SEMAPV with ManualAudit/AutomatedScan/DocumentReview/InterviewEvidence/TestResult/InheritedControl), and propagatable MappingSet defaults (adapted as _defaults.md folder templates applied by Templater).

File 2 doesn’t mention SSSOM at all. File 1 is the sole source for this thread. The proposal is novel — there’s no prior art for using SSSOM in compliance contexts, but the mechanical fit is clean. Open sub-question: should Crosswalker commit to the SSSOM-borrowed fields now, or defer until the primary schema is locked?

3. Pivot table feasibility

Section titled “3. Pivot table feasibility”

File 2 documents that pivot tables / cross-tabulation are “fundamentally impossible” in Dataview and Bases without a new rendering engine — neither tool can dynamically create columns from data values (the core pivot operation of transposing row values into column headers). Cites the May 2025 “Cross Tables in Bases” feature request as evidence the limitation is acknowledged upstream.

File 1 assumes Bases’ grouped views and summary functions are sufficient for reporting, and doesn’t discuss pivot tables or cross-tabulation. Open sub-question: does Crosswalker require a compliance matrix view (controls × evidence as a cross-tabulated grid)? If yes, that’s a Tier 2/3 feature requiring SQL or a custom rendering path — and the Tier 1 Bases experience has to be scoped as “grouped views + summary counts only.”

4. Inline Dataview field deprecation — is the original design still active?

Section titled “4. Inline Dataview field deprecation — is the original design still active?”

File 2 documents Crosswalker’s current five-level metadata priority system using inline Dataview tags with dot notation (framework_here.applies_to:: [[AC-2]] {"sufficient": true}) and quotes cybersader’s own January 2025 Obsidian Forum post describing this approach.

File 1 completely abandons this pattern, calling inline approaches unscalable and Bases-incompatible. This is a direct tension: File 2 treats the original design as active, File 1 treats it as mandatorily superseded. Resolution: per the morning’s Foundation synthesis commitment to Obsidian Bases (not Dataview), File 1 is correct — the inline approach is deprecated in favor of junction notes. The link-metadata-system page already carries a caution callout marking it stale; this log strengthens that to “superseded.”

5. Scale thresholds

Section titled “5. Scale thresholds”

File 2 has hard data: 4-second link-selector delays at very large vault sizes, graph view unusable beyond ~6,000 densely linked notes (27,000+ links), users resorting to external tools like Cosmograph (WebGL) for visualization. File 1 proposes thousands of junction notes without tested data on where the pattern breaks. Open sub-question: what vault sizes does Crosswalker target? (Propose: document 10,000 junction notes as the tested threshold, warn at 20,000+.)

The 4 storage candidates from Challenge 07 — why all 4 fail Bases

Section titled “The 4 storage candidates from Challenge 07 — why all 4 fail Bases”

Challenge 07 listed 4 candidate storage shapes for evidence-link metadata. The research evaluates all 4 against Bases’ constraints and shows why each fails — then proposes junction notes as a 5th option Challenge 07 didn’t anticipate.

The proposed 13-field junction note schema

Section titled “The proposed 13-field junction note schema”

File 1 proposes a concrete schema, reproduced here verbatim. Each of the 13 frontmatter fields is a flat scalar or wikilink — all directly queryable by Obsidian Bases, all mapped to concepts from OSCAL, SSSOM, or established GRC-tool conventions.

Vault folder structure

Section titled “Vault folder structure”

Why O(E) scales, not O(N²)

Section titled “Why O(E) scales, not O(N²)”

The alternative architectures Challenge 07 listed all required per-target fields on the evidence or control notes themselves — a 2-evidence vault mapping to 3 controls would need control_1_status, control_2_status, control_3_status as separate frontmatter fields. That’s O(N²) in the combined evidence × control count. Junction notes grow O(E) in the actual edge count — only edges that exist generate files.

Three-dimensional status vocabulary

Section titled “Three-dimensional status vocabulary”

Challenge 07 asked for “a status vocabulary” and listed five candidates: minimal, OSCAL-aligned, status+coverage, status+lifecycle, compound. File 1’s answer is three orthogonal dimensions, each drawn from established GRC standards — not one compound status enum.

Why each dimension exists

Section titled “Why each dimension exists”
  • status (5 values, from OSCAL metaschema, allow-other="no") — answers the core compliance question: is the control satisfied? Values: implemented, partial, planned, alternative, not-applicable. Compatible with ISO 27001 SoA, OpenControl (complete/partial/planned/none), and CMMC binary MET/NOT MET.
  • freshness (4 values, computed from collected + expires) — answers “is the evidence still valid?” Values: fresh / stale / expired / not-set. The stored fields are collected and expires; freshness itself is a derived Bases formula column. Inspired by Hyperproof’s first-class freshness model and Auditree’s TTL pattern — but stored-freshness can go stale itself, which is why File 1 makes it computed.
  • evidence_type (8 values, synthesized from OSCAL Assessment Methods + Auditree + Drata + Anecdotes) — answers “what kind of evidence is it?” Values: policy-document, automated-scan, test-result, configuration, log-export, interview, architecture-review, attestation.

Git history as audit trail — with 3 hardening measures

Section titled “Git history as audit trail — with 3 hardening measures”

Both files converge on git commit history as the native audit mechanism. Every junction note edit is a commit with author, timestamp, diff, and message. git log -p -- links/MFA-Policy--NIST--AC-2.md produces a complete audit trail of every status change, reviewer reassignment, and narrative update on that specific edge.

The research confirms git’s Merkle-tree hash chain provides tamper-evidence comparable to blockchain. Kosli (backed by Deutsche Bank) and Auditree both use git repositories as compliance evidence stores in production.

But git is not inherently immutable — force-push, rebase, and commit --amend can rewrite history. File 1 identifies three mandatory hardening measures:

  1. Signed commits (GPG or SSH) — binds changes cryptographically to verified identities. Without signing, user.name and user.email are trivially spoofable. GitHub/GitLab both support “Reject unsigned commits” as a repository rule.
  2. Branch protection preventing force-push to main. All changes via pull request with required reviews — the PR itself becomes an auditable approval record. Combined with signed commits, this makes rewriting history effectively impossible post-merge.
  3. Periodic snapshots to an external, append-only store. Auditree’s auditree-harvest pattern collates evidence over time; a simpler approach is git tags at each review cycle, pushed to a protected archive repository. File 1 notes this is belt-and-suspenders for organizations that want Merkle-chain tamper-evidence anchored outside their primary repo.

Known limitation: git doesn’t track reads — only writes. For access auditing (who viewed the vault), Crosswalker must rely on the hosting platform’s audit log API (GitHub Enterprise, GitLab audit events). For the local-first constraint this is acceptable; the primary audit need is change provenance, not read access.

OSCAL round-trip viability

Section titled “OSCAL round-trip viability”

The junction note schema is deliberately isomorphic to OSCAL’s SSP by-component assembly. File 1 produces a field-by-field mapping table, reproduced here:

Junction note fieldOSCAL SSP pathOSCAL type
evidencesystem-implementation/components[uuid]Component reference
controlcontrol-implementation/implemented-requirements[control-id]Control reference
statusby-components[]/implementation-status/stateToken enum (5 values)
narrative bodyby-components[]/descriptionMarkup-multiline
responsibleby-components[]/responsible-roles[]/party-uuidsUUID reference
reviewermetadata/responsible-parties[role-id="reviewer"]Party reference
review_datemetadata/actions[type="approval"]/dateDateTime
methodAssessment Results observations[]/methods[]EXAMINE / INTERVIEW / TEST
confidenceCustom prop (no OSCAL native equivalent)Float via namespaced prop
collectedAssessment Results observations[]/collectedDateTime
expiresAssessment Results observations[]/expiresDateTime
evidence_typeComponent type or custom propToken

Round-trip viability is high but not lossless. Two loss points:

  1. OSCAL requires UUIDs on every object. Junction notes don’t natively carry UUIDs. The export script would generate deterministic UUIDs (v5, namespaced by vault + filepath) at conversion time. Re-import would need to preserve them somewhere — either as a new frontmatter field or in a .oscal-uuids.json sidecar. Choose one in the follow-up design pass.
  2. OSCAL by-component allows statement-part granularity (e.g., AC-2(a), AC-2(b)) — multiple components per control per statement-part. Junction notes currently operate at the control level. File 1 suggests the junction note filename convention can be extended for statement-level granularity: MFA-Policy--NIST--AC-2--smt-a.md.

For Assessment Results export, the chain is:

junction notes with method + collected fields
      ↓
OSCAL observations with relevant-evidence hrefs pointing to evidence files
      ↓
OSCAL findings with target/status/state derived from the status field

The confidence field has no OSCAL native equivalent but maps cleanly to a namespaced prop: {"name": "confidence", "ns": "https://crosswalker.dev/ns", "value": "0.85"}.

New formal concepts and standards the research introduced

Section titled “New formal concepts and standards the research introduced”

These aren’t in the Foundation vocabulary yet but the research leans on them. Each deserves a short definition now so future logs and concept pages can cite them.

ConceptSourceOne-line definitionRelevance to Crosswalker
ReificationMungall 2020 (Berkeley Lab blog), RDF 1970sMaking a statement about a statement — turning an edge into a node so you can attach metadata to itThe formal name for what junction notes are
Junction note / edge-as-noteFile 1 (proposed); etothepiiminus1 2021 (Obsidian Forum never-built “Edge Notes” plugin proposal)A markdown file whose entire purpose is to represent one link, with the link’s metadata in its frontmatterThe recommended architecture
OSCAL by-component assemblyNIST OSCAL SSP modelThe OSCAL structure for “this component satisfies this control in this way” with implementation-status, description, responsible-rolesThe export target — junction schema is isomorphic to this
OSCAL Assessment MethodsNIST OSCAL Assessment PlanEXAMINE, INTERVIEW, TEST — the three standard ways an auditor verifies a controlThe method field’s vocabulary
SSSOM dual-confidence scoringMatentzoglu et al. 2022 (Database)Separates confidence (author’s estimate) from reviewer_agreement (reviewer’s agreement, -1.0 to +1.0)File 1 proposes borrowing this as a pair of numeric fields for dual-attestation
SEMAPV (Semantic Mapping Vocabulary)W3C / SSSOM-adjacentControlled vocabulary for mapping_justification: ManualMappingCuration, LexicalMatching, MappingReview, etc.File 1 proposes a compliance-specific extension: ManualAudit, AutomatedScan, DocumentReview, InterviewEvidence, TestResult, InheritedControl
Hyperproof freshness modelHyperproof (commercial GRC tool)First-class automated freshness states (Fresh / Expired / Unknown / Not set)File 1 adapts as a computed Bases column
AuditreeIBM open sourceCompliance-as-code framework using git as evidence store with TTL semantics and StaleEvidenceError exceptionsValidates the git-as-audit-trail pattern; inspires expires field
KosliCommercial, backed by Deutsche BankProduction compliance-as-code platform using git repositories as evidence stores with Merkle-tree tamper-evidenceEvidence that git-based audit is enterprise-viable
RDF-star / SPARQL-starW3C emerging standardSyntactic extension allowing triples to serve as subjects: <<:P1 :interacts-with :P2>> :supported_by :pmid123. Supported by Stardog 7.1+Cited as the ideal formal solution that PKM tools haven’t adopted; points at where the space is heading
Meta-Property GraphsNguyen et al. 2025, EDBT (arXiv:2410.13813)Formal model extending property graphs with “metadata awareness and reification”Academic formalization of the junction note pattern
RIO — Roam Internal OntologyNikolas Kolev153-class, 45-property ontology within Roam Research leveraging block-level attributes for reificationPrior art in another PKM tool; closest native-edge-metadata implementation found
”Edge Notes” plugin proposaletothepiiminus1, April 2021, Obsidian ForumNever-built plugin that would auto-reify labeled links into notes, forming clickable triangles in graph viewDirect prior art in the Obsidian community; the idea has been circling for 5 years
CRDT reconciliationShapiro et al. 2011Conflict-free Replicated Data Types for eventual-consistency distributed editing. OneNote uses this for multi-user conflict handlingRelevant if evidence-link editing ever goes multi-user; out of scope for Foundation

Decisions this forces

Section titled “Decisions this forces”

Ready to commit now (the research is strong enough — both files converge, schema is concrete, Bases constraints are airtight):

  1. Adopt junction notes as the evidence-link edge architecture. Storage shape is decided. The 4 candidates in Challenge 07 all fail the Bases constraints; the research proposes a 5th shape (reify each edge as its own file) and both research sessions independently recommend it.
  2. Adopt the 13-field schema as the base set: link_type, evidence, control, framework, status, confidence, evidence_type, method, reviewer, review_date, responsible, collected, expires, freshness (computed), plus optional supersedes for review chains.
  3. Commit to the three-dimensional status vocabulary: status (5 OSCAL values) + freshness (4 values, computed) + evidence_type (8 values). Reject the compound-status approach.
  4. Commit to OSCAL by-component as the canonical export target. The schema is deliberately isomorphic; round-trip is high-fidelity (with UUID and statement-part caveats documented).
  5. Commit to git history as the audit trail with the 3 hardening measures (signed commits, branch protection, periodic external snapshots).
  6. Borrow from SSSOM selectively: dual-confidence scoring (confidence + reviewer_confidence) and the compliance-extended mapping-justification vocabulary.

Open sub-decisions — NOT research gaps, just design calls that follow from the Foundation commitment above:

  1. UUID enterprise resilience scope. File 2 flags filename-based linking as fragile across out-of-app moves. Decide: does Foundation scope include enterprise multi-user resilience (UUID field added to the schema), or is local-first vault integrity sufficient for Tier 1? If out-of-scope, document the assumption explicitly.
  2. Tier 2 sql.js sidecar schema mapping. Design task: what’s the SQL table structure for junction note data? How does it round-trip with Tier 1 YAML? Not research — design work downstream of this decision and the Progressive tier architecture pillar.
  3. Challenge 06 synthetic spine integration. Do evidence links target framework controls directly, or do they flow through the synthetic spine (evidence → spine-concept → framework)? Has implications for the “this evidence automatically covers equivalent controls in other frameworks” story.
  4. Vault scale threshold documentation. Propose: document 10,000 junction notes as the tested Tier 1 threshold, warn at 20,000+. Requires actual perf testing; not research.
  5. Mandatory vs optional field marking. File 1 lists 13 fields but doesn’t formally mark which are non-nullable. Propose: link_type, evidence, control, framework, status are mandatory; rest are optional. Lock this in during the follow-up design pass.
  6. Multi-editor conflict resolution. With git as audit trail, what happens when two reviewers set different statuses on the same junction note simultaneously? Standard git merge conflict, or first-writer-wins? Not blocking but worth specifying.
  7. Inline Dataview field migration path. The original link-metadata-system design proposed inline Dataview syntax. This log supersedes that. Migration for any existing vaults using the old pattern: write a one-shot script that converts inline framework_here.applies_to:: fields to junction notes. Document as a v0 migration task.

What this log does NOT decide

Section titled “What this log does NOT decide”

Per Challenge 07’s “out of scope” section, plus discovered caveats:

  • Full evidence-mapping workflow — how evidence gets imported, the linking UX, gap surfacing, reports, dashboards. That’s the separate Evidence mapping workflow roadmap item
  • Tier 2 sql.js sidecar exact schema — downstream design task
  • Obsidian plugin UI design — product iteration on top of the committed edge schema
  • Enterprise multi-user editing with CRDTs — flagged by File 2 as adjacent; explicitly out of Foundation scope
  • Pivot-table / cross-tabulation reporting — File 2 documents Bases cannot do this; if Crosswalker needs it, that’s a Tier 2 SQL feature, documented as an intentional Tier 1 limitation
  • Vault scale perf testing — needs actual benchmark runs, not research synthesis
Section titled “Related”

External references the research cites: