« Phase 07 · Warmup · Track Overview

Staff Notes — Judgment, Review Signal & Seniority

Table of Contents

• 1. Build vs buy
• 2. Should this be a graph at all?
• 3. Review red flags
• 4. Production war stories
• 5. The interview signal
• 6. Mentoring notes

1. Build vs buy

The line, as everywhere: buy the mechanics, build the meaning. The store is a database. The ontology is a negotiated agreement about what a counterparty is, and no product ships that.

One warning specific to this phase: it is tempting to write your own triple store because the lab makes it look easy. The lab is easy — it has no persistence, no transactions, no planner and no concurrency. Those four are the product, and each one is a year.

2. Should this be a graph at all?

The question to ask before any of the above, because the enthusiasm-to-value ratio here is high.

Use a graph when:

• the questions are about paths of unknown length — ownership, exposure propagation, counterparty chains;
• meaning must cross an organizational boundary and a shared vocabulary is the point;
• the schema is genuinely open — new relationship types arrive regularly and a migration per type is untenable;
• federated queries over external registers are on the roadmap.

Do not, when:

• the joins are fixed-depth and known — that is SQL, and SQL will be faster and better understood;
• there is one owner and no vocabulary problem — an LPG will be simpler, or a table will;
• the real requirement is document search — Phase 06 covers it;
• nobody can name three queries that need a variable-length path.

That last test is the one to use in a design review, and it is decisive. "Give me three questions you cannot answer with a two-table join." If they cannot, the proposal is enthusiasm rather than a requirement, and the honest recommendation is to revisit it when they can.

The common failure is adopting RDF for an internal operational graph: you take on IRIs, reification, an unfamiliar query language and a scarce skill set, in exchange for federation and formal semantics you never use.

3. Review red flags

In a design document

• No named-graph strategy — asserted and derived in one undifferentiated store.
• No answer to "what happens when a source triple is deleted?"
• Text-to-SPARQL, i.e. the model generating queries against a live endpoint.
• Unbounded property paths in anything an agent can trigger.
• No query timeout or result limit on the endpoint.
• Full OWL 2 DL reasoning proposed, with no named construct that needs it.
• The ontology has no owner, or the owner cannot say no.
• FIBO "adopted" wholesale, with no module scoping.
• Graph data treated as metadata, with no classification or barrier model.
• SHACL described as validating "eventually", on a schedule, rather than at ingestion.
• owl:sameAs produced automatically by a matching pipeline with no threshold and no review.
• No plan for ontology versioning, or a plan that includes deleting classes.

In modelling

# Red flag: a constraint expressed in OWL
bank:LegalEntity owl:minCardinality 1 ; owl:onProperty bank:hasLEI .
  # infers an unseen LEI; rejects nothing. This is SHACL's job.

# Red flag: transitivity declared because it "seems natural"
bank:relatedTo rdf:type owl:TransitiveProperty .
  # everything is now related to everything, and the closure is quadratic

# Red flag: an IRI reused for a new concept
bank:Customer  # was "an account holder", now "a party we have onboarded"
  # every consumer's meaning silently changed

# Red flag: unbounded path in a tool an agent can call
SELECT ?x WHERE { ?a ?p+ ?x }

In code

# Red flag: validating before materializing
validate(graph, shapes)          # nodes typed only by inference are silently skipped
materialize(graph)

# Red flag: no visited set
def walk(node, pred):
    for nxt in objects(node, pred):
        yield from walk(nxt, pred)     # circular ownership -> stack overflow

# Red flag: inner join where OPTIONAL was meant
?owner bank:controls+ ?target .
?owner bank:legalName ?name .          # hides the unnamed shell company

# Red flag: derived and asserted indistinguishable
graph.add(subject, predicate, obj)     # which graph? which rule produced it?

In an incident review

• "The ownership report was wrong for six weeks" → stale closure after a delete.
• "The query never returned" → unbounded path, no timeout, or a cycle with no visited set.
• "Two customers got merged" → owl:sameAs from an unreviewed matching pipeline.

4. Production war stories

The stale closure. A majorityOwns triple was corrected at source. The materialized controls closure was not recomputed — there was no separation between asserted and derived, so nobody knew which triples depended on it. Ownership reports were wrong for six weeks, and nothing errored, because a derived triple is indistinguishable from an asserted one.

The KYC query that hid the shell. An ownership query inner-joined on legalName. The entity with no name and no LEI — precisely the one an analyst is looking for — was absent from every result. OPTIONAL would have surfaced it, and the fix was one keyword.

The traversal that never returned. Two companies owning each other, which is a legitimate and deliberate structure. No visited set in the application-side traversal. The job ran until it was killed, three times, before anyone drew the graph.

Everything related to everything. Someone declared relatedTo transitive because it read naturally. The closure over a densely connected register grew until the store was mostly derived triples, and every relatedTo query returned the whole graph.

The merge that propagated. An entity-resolution pipeline emitted owl:sameAs on a name-and- country match above 0.85. One false positive merged two unrelated companies, and the reasoner propagated every fact about each onto the other — including a sanctions flag. It took a week to untangle because the derived triples had no attribution.

The two-year ontology. No owner with authority to refuse. Every team's concepts were added because each request was individually reasonable. Four thousand classes later, the reasoner took hours, nobody understood the model, and the conclusion drawn was "semantic technology doesn't work" — when what had failed was governance.

Text-to-SPARQL. An agent generating queries against the live endpoint. An unbounded property path took the store down during a demo. There was no timeout because nobody had considered the endpoint an attack surface.

The silent reasoning upgrade. A ruleset was changed from RDFS to OWL-Horst during a routine upgrade. Queries started returning more rows — correctly — and three downstream reports broke. The ruleset had not been versioned alongside the ontology.

5. The interview signal

Signal 1 — "OWL infers, SHACL validates", with the open-world reason. Not the slogan alone, but the follow-through: the OWA means OWL concludes an unseen LEI rather than flagging a missing one, which is exactly the KYC question. This is the single most distinguishing answer in the phase.

Signal 2 — you show two rules composing. majorityOwns ⇒ controls then transitivity, producing a fact nobody asserted. It demonstrates that you understand entailment as derivation rather than as a stored view.

Signal 3 — you volunteer the deletion problem. "Entailment is monotone, so adding is always safe; deletion breaks a materialized closure and derived triples look exactly like asserted ones." Then the fix — separate named graphs — and the audit benefit that comes with it.

Signal 4 — asserted versus derived as an audit question. "An examiner asks on what basis we concluded Meridian controls Acme, and 'we don't know whether that was told to us or inferred' is not an acceptable answer."

Signal 5 — you refuse text-to-SPARQL. Parameterized, bounded query tools with the caller's entitlements applied. This shows you have connected the graph to the rest of the platform rather than treating it as a database.

Signal 6 — you say when not to use a graph. Three questions needing a variable-length path, or it is SQL. Candidates enthusiastic about knowledge graphs are common; candidates who can scope one are rare.

Signal 7 — the graph carries classification. ent:Acme involvedIn ent:ProjectFalcon is MNPI as a triple. Very few people notice that the relationship is the sensitive fact.

Anti-signals:

• Expecting OWL to catch missing data.
• Proposing full OWL 2 DL with no named construct requiring it.
• No answer to "what happens on delete?"
• Treating the ontology as a schema you can migrate.
• Adopting all of FIBO.
• Free-form SPARQL from a model.
• No mention of cycles.

The question to ask them: "Do you separate asserted from derived triples, and who owns the ontology?" The first tells you whether the deletion and audit problems have been thought about; the second tells you whether the ontology has a future.

6. Mentoring notes

Three exercises, in order of how much they change behaviour:

1. Ask for three questions that need a variable-length path. Before any modelling. Most teams discover their requirement is a two-table join, and the ones with real answers now have a scoped project rather than an open-ended one.
2. Delete a triple, then run the ownership query. Watch the wrong answer come back with no error. Then show the named-graph fix. This is the fastest way to make materialization's cost concrete, and it permanently changes how someone thinks about derived data.
3. Hand them the shell-company query with an inner join. Ask why the most suspicious entity is missing. The realization that a join choice can hide exactly what you are looking for is worth more than an explanation of OPTIONAL.

And one framing for the platform team: an ontology is a negotiated agreement, so its failure modes are organizational, not technical. The store will be fine. What kills these projects is an ontology with no owner, growing to the union of everyone's schema, until the bank has the mapping problem it adopted RDF to avoid — plus an unfamiliar query language and a scarce skill set. Ask for the owner and the change process before asking for the store, and adopting FIBO helps here for a non-technical reason: it gives you an external authority, so "control means what FIBO says" is a defensible position rather than one team's opinion.