The KTP mechanism
Trajectory is identity: a graph is the record of standing over time, and a product ID is a mapping, never the key. In KTP an agent is what it has been doing, witnessed and chained. A knowledge graph built for governed autonomy is that record for a whole estate: cases, findings, hosts, identities, services and the parties that touch them, joined by identity rules no product owns. When two graphs meet, the seam keeps each side's namespace, and what crosses it arrives as an observation with a loss and a clock.
The working form, from the workbook
One graph, product-neutral, with join identity. Twenty-one node types and nineteen edge types with their rules. Five interface layers between graphs (identity, meaning, trust, access, exchange) and three exchange patterns. Ten gates the mesh must pass. Rules for nested and peer graphs, no transit, bilateral identity. Twenty-six invariants, KG-1 to KG-26.
Where it is written down
Acequia, Inc. is an invented organization. These pages present a working design, not deployment results; its contracted stages and change freezes are illustrative. The sections below mirror the Governed Autonomy workbook (v0.50): its columns, rules, invariants and catalogs, as written, with the worked example's organization named as it is there. The deployment's own rows, parties, contract identifiers and configuration stay with the deployment; where a table's rows stay, its columns are shown.
On this page 18 sections · 190 rows · about 11 min to read plus 56 catalog rows to browse · from tabs Knowledge graph, Detection registry, Detection schema, Detection version
01 What the graph is 9 rows 02 What to create — node types 21 rows 03 What to create — edge types 19 rows 04 What to create — identity rules 6 rows 05 How to create — mesh rules 5 rows 06 Build order 8 rows 07 Interfaces between graphs — layers 5 rows 08 Interfaces between graphs — coordinates 6 rows 09 Interfaces between graphs — rules 6 rows 10 Interfaces between graphs — exchange patterns 3 rows 11 Gates the mesh will pass 10 rows 12 Beyond the core — what each area settles 12 rows 13 Nested and peer graphs — rules 11 rows 14 Nested and peer graphs — gates 7 rows 15 Observation classes — crosswalk to OTCS-0020 6 rows 16 Detection identity: the registry's fields schema 17 Detection schema: the field contract 56 rows 18 Detection version: logic lineage and rollback schema 01 What the graph is workbook tab 07 · Knowledge graph What this is for. How to build the shared map of the case as plain files that any tool can read.
Each organization keeps its own graph. A shared map can sit inside a larger one or meet another as an equal, and each keeps its own names. How to use it. Read what to create, then the file layout, then the build order. A worked example and a checker ship with the specification.
One join graph across the six seats. Every node is a plain file: any graph store can load it, and no product is needed to rebuild it. A product's own graph is one source. A Join can sit inside a larger Join, or connect as a peer with another organization's Join. The Mission Join
1. What the graph is — one join graph, product-neutral
¶ One graph
The join graph holds one Case and the shared identifiers on it: host, identity, service, venue, owner, journey, playbook step, field, and context object.
¶ Product-neutral
Every node is a plain file. Any graph store can load it. No product is required to rebuild it.
¶ Join identity
The join graph mints every join ID. A product ID is a mapping onto a join ID. It is never the join key.
¶ Sources
A product's own graph, a case system, an ITSM, and a field model are sources. Each one maps onto join IDs.
¶ Two or more graphs
Organizations keep their own graphs. Each one connects to a Join through a profile and a declared interface (section 7).
¶ Nested and peer Joins
A Join is a graph too. It can nest inside a larger Join or peer with another organization's Join (section 10).
¶ Mission Join
This six-seat Join nests inside the Mission Join, which joins IT groups, business departments and the Mission through the work each does (section 11; Mission Join tab).
¶ Not the program graph
The join graph is separate from the program graph at data/graph.json. A PTY:: code maps to an org:* identifier there.
¶ Contract
the knowledge graph specification is the Markdown contract. This tab and that file say the same thing.
02 3. What to create — node types workbook tab 07 · Knowledge graph ¶ Case
Process spine state 0–7. One spine.
¶ Finding
Qualification state. Raised by one Detection.
¶ Observable
Normalized fact: IP, domain, hash, URL, user, host, session, email artifact, or composite identity event.
¶ Host
Member of the entity graph. IP, hostname, DNS, and asset tag are identifiers on the node.
¶ Identity
Kind: workforce, visitor/volunteer, service account, or privileged.
¶ Service
Accountable owner (PTY::).
¶ Venue
Network, access, and operational boundary.
¶ Journey
End-to-end service path: participant, media, workforce, or visitor.
¶ Party
Four digits, extensible to five. Main name and second name, both required.
¶ Join seat
Exactly these six in this Join. A seat is not a party. The Mission Join
¶ Context object
Observation class (DIR ENU ADJ PUB DER envelope
¶ Detection
Stable detection identity. Versioned logic lives on Detection version.
¶ Field
Field-contract model and field name.
¶ Source contract
Telemetry source a Detection requires.
¶ playbook step
The step on a playbook family procedure.
¶ ITSM task
Incident, change, or request. Linked to one Case.
¶ Session
Purpose, lineage, action class, revoke path. V3.
¶ Platform release
As-of and validity horizon.
¶ mission horizon
Acequia, the next peak operating window, the peak operating window after it.
¶ Source graph
Owner (PTY::), profile, exchange pattern, and kind: source or join.
Show 1 more of 21 03 3. What to create — edge types workbook tab 07 · Knowledge graph ¶ has-finding
Case
To Finding
Rule A Finding sits on one Case. ¶ has-observable
Case
To Observable
Rule Many-to-many. ¶ about
Finding
To Host, Identity, Service, Venue, or Journey
Rule The Finding names the entities it describes. ¶ raised-by
Finding
To Detection
Rule Many-to-many. ¶ on-case
Case
To Host, Identity, Service, Venue, or Journey
Rule The shared identifiers for this Case. ¶ owned-by
Service or Case
To Party
Rule Owner is this edge. Owner is not a node type. ¶ occupies
Party
To Join seat
Rule A party occupies one or more seats. A new party gets no new seat. ¶ at-step
Case
To playbook step
Rule The playbook consumes the Case. The playbook is not the ontology. ¶ opens-task
Case
To ITSM task
Rule Closing the task leaves the Case open until the acceptance authority closes it. ¶ constrains
Context object
To Case or Session
Rule Written only when the envelope ¶ declared-by
Context object
To Party
Rule The party that owns the object. ¶ binds
Session
To Context object
Rule V3 writes declared objects onto the session. ¶ attaches-release
Platform release
To mission horizon
Rule A release attaches to a mission horizon. It does not open a joint version. ¶ conflict
Entity
To Entity
Rule Two canonical IDs for one real object. Both nodes remain. No silent merge. ¶ published-by
Source graph
To Party
Rule Each source graph has one owner. ¶ connects
Interface
To Source graph
Rule A member interface connects source graphs through a Join. A peering interface connects Joins only. ¶ nested-in
Join
To Join
Rule The child Join is a member of the parent Join. At most one parent per Join. ¶ authoritative-for
Party
To Interface
Rule Carries a scope: the node type or property. One authoritative party per scope. ¶ Detection links edges
Detection
To Source, layer, field, entity, signal, outcome, technique, control
Rule As specified on Detection links and in the detection ontology map. 04 3. What to create — identity rules workbook tab 07 · Knowledge graph ¶ One canonical ID
Each real object has one join ID. Other identifiers are properties on that node.
¶ Conflict, not merge
A second canonical ID for the same object is a conflict edge. Both nodes stay.
¶ Product IDs map
A product ID maps onto a join ID in mappings/. It never mints a join node.
¶ Envelope first
A context object carries its envelope DIR ENU ADJ PUB DER
¶ Unknown
A missing node, edge, membership, or source is written as unknown. Never zero, false, or no-risk.
¶ Contract change
Renaming or removing a join ID is a contract change.
05 4. How to create — mesh rules workbook tab 07 · Knowledge graph ¶ Links are IDs
A link is a join ID. Paths and titles are not links.
¶ Broken link fails
A link to an ID with no node file fails the gate.
¶ Absence is unknown
Absence is written as unknown.
¶ Mappings never mint
A product mapping never mints a join node.
¶ Rename is a contract change
Renaming an ID is a contract change.
06 5. Build order workbook tab 07 · Knowledge graph 07 7. Interfaces between graphs — layers workbook tab 07 · Knowledge graph 08 7. Interfaces between graphs — coordinates workbook tab 07 · Knowledge graph ¶ Actor
Party, Identity, Join seat
¶ Authority
owned-by, declared-by, authoritative-for, Session revoke path
¶ Action
playbook step, ITSM task, Session action class
¶ Environment
Context object with its envelope
¶ Time
Joint maturity, platform train, mission horizon; envelope as-of and validity horizon
¶ Evidence
Observation class, Detection links, crosswalk evidence
09 7. Interfaces between graphs — rules workbook tab 07 · Knowledge graph ¶ Through a Join
Source graphs connect only through a Join. Joins connect by nesting or by peering. N graphs need N profiles, not a mapping per pair.
¶ No profile, no mapping
A source graph without a profile has no mapping.
¶ No minting
Profiles and interfaces never mint join nodes.
¶ Provenance or no constraint
A cross-graph fact without asserted-by, as-of, and observation class
¶ Absence is unknown
A fact the other graph does not supply is unknown, not no.
¶ Expiry
An expired interface supplies only unknown.
10 7. Interfaces between graphs — exchange patterns workbook tab 07 · Knowledge graph ¶ Federated query
Each graph answers queries against itself; the Join combines answers at query time.
Fits when Data is sensitive or changes fast. ¶ Join-held
The Join holds only shared identities and cross-graph edges, and points into each source.
Fits when Many parties work one shared case. Not between peers. 11 8. Gates the mesh will pass workbook tab 07 · Knowledge graph Each gate names what fails and the invariant it protects.
¶ No dangling link
A link names an ID with no node file.
¶ Declared types only
A node or edge has a type not declared in kg/schema/.
¶ Envelope before constrains
A constrains edge comes from a context object without a complete envelope
¶ Exactly six seats
This Join (the nested Case Join) has a seat other than CYB, ITO, APO, GOV, REG, or CMP.
¶ No product join key
A product ID is used as a join ID, or a join node exists only through a mapping.
¶ Profile before mapping
A mapping exists for a source graph with no profile.
¶ Complete interface
An interface connects fewer than two graphs, or lacks an owner, purpose, or expiry.
¶ Crosswalk provenance
A crosswalk pair has no asserted-by or as-of.
¶ One authority per scope
Two parties are authoritative for the same scope on one interface.
¶ Expired means unknown
An expired interface still supplies facts.
12 9. Beyond the core — what each area settles workbook tab 07 · Knowledge graph ¶ Time
Every fact carries valid time and recorded time. Replay, diff, and trajectory answer what the Join knew at a decision.
¶ Records and provenance
Every node and edge is a record with asserting party, source graph, observation class
¶ Schema and serialization
JSON Schema per type, a plain front-matter format, content hashes, and additive-only schema change.
¶ Identity lifecycle
IDs are opaque and never reused. Merge is same-as, split is derived-from, retirement is a tombstone.
¶ Derivation
A derived edge names its rule and rule version, and reads as derived, never observed.
¶ Sensitivity and retention
Every record carries a label and a retain-until date. An interface caps the label that crosses it.
¶ Supply chain
Every input records producer, version, and content hash. Unsigned inputs are pending. Revoked inputs are suspended. Components, suppliers, concentration, exposure.
¶ Views
2D, 3D, and 4D are saved queries over kg/, regenerated by any tool.
¶ Partitioning
By mission horizon, then Case. Never by tool, vendor, or organization chart.
¶ Custody and durability
A named steward, a handover record, signed commits as the ledger, and no vendor dependency.
¶ Competency questions
Sixteen questions the graph must answer, kept as regression tests.
¶ Starter kit
One worked a playbook Case as plain files, with a validator. Placeholder data only.
13 10. Nested and peer graphs — rules workbook tab 07 · Knowledge graph ¶ Joins are graphs
A Join is a source graph of kind join. Source graphs connect only through a Join. Joins connect by nesting or by peering.
¶ Nesting
A child Join publishes a profile to its parent and holds one nested-in edge. The parent maps the child's IDs and never edits its records.
¶ Tree
A Join has at most one parent, and no Join is its own ancestor. Depth is not limited.
¶ Qualified IDs
A join ID belongs to the Join that minted it. Other Joins refer to it as GRAPH::<id>/<join ID> and never rewrite it.
¶ Upward unchanged
Unknown, expiry, pending, and suspended pass upward unchanged. Revoking a child Join suspends everything that came through it.
¶ Peering
Joins owned by different organizations connect as equals over a peering interface. Neither one mints or owns identity for the other.
¶ Bilateral identity
A peer identity match constrains only when both Joins assert it. A one-sided match is a claim and does not constrain.
¶ No precedence
Disagreement between peers is a conflict edge. The interface names one authoritative party per scope.
¶ No join-held between peers
A peering interface uses federated query or published extract. No single Join holds the shared identity.
¶ No transit
A fact that arrived over one peering interface does not leave over another. Each peer relationship is agreed directly.
¶ Provenance chain
A fact that crossed a nesting or peering hop names every graph it passed through, origin first.
14 10. Nested and peer graphs — gates workbook tab 07 · Knowledge graph ¶ Nesting is a tree
A Join has two parents, or a nesting chain returns to its start.
¶ Nesting connects Joins
A nested-in edge touches a graph that is not a Join.
¶ Qualified ID resolves
A qualified ID names a Join that is neither nested with this Join nor peered with it.
¶ Peer identity is bilateral
A peer match marked bilateral is asserted by one side only.
¶ Peering excludes join-held
A peering interface declares join-held, or connects a graph that is not a Join.
¶ No transit across peers
A fact from one peer is shared over another peering interface.
¶ Chain after a hop
A fact from a child or peer Join does not name the graphs it passed through.
15 12. Observation classes — crosswalk to OTCS-0020 workbook tab 07 · Knowledge graph The workbook's five classes, mapped to OTCS-0020. A derived edge is configured; it is not a derived state.
¶ DIR
direct
Statement One instrument samples a quantity. Same envelope ¶ ENU
counted
Statement A figure computed over a counted set. It names its membership rule and that rule's version. ¶ ADJ
adjudicated
Statement A named authority recorded it. The deployment is never its own adjudicator. ¶ PUB
published
Statement A third party's number. It keeps its publisher, series and vintage wherever it is used. ¶ DER
configured
Statement A state read from a calendar, configuration or table, with as-of and validity horizon. ¶ Derived edge
none
Statement A derived edge keeps the class of its inputs and names its rule and rule version. It is not DER. 16 Detection identity: the registry's fields workbook tab 23 · Detection registry The three detection tabs travel as a pattern: a durable identity, a field contract with a lifecycle scope, and a logic lineage with rollback. The deployment's detections stay with it.
The columns · the rows stay with the deployment
Detection key Detection name/title Data Analytics Provider detection ID Description App Release version Logic version Disabled Enablement status Configuration basis Owner Evidence link status Acceptance state Review date Created at Updated at Modified by Configuration Field contract Relationship map Migration archive Version history 17 Detection schema: the field contract workbook tab 25 · Detection schema 56 of 56 Full Compact
Canonical type All canonical type · 56 Enum · 11 Relationship set · 10 Reference · 8 Boolean · 3 Date · 3 Identifier · 3 String · 3 Version · 3 Data Analytics Provider relative time · 2 Timestamp · 2 Cron expression · 1 Data Analytics Provider duration · 1 Duration or percentage · 1 Enum or integer · 1 Hash · 1 Number · 1 Reference or text · 1 search-language text · 1
Lifecycle scope DURABLE · 51 MIGRATION_ONLY · 5
Show 20 more of 56 18 Detection version: logic lineage and rollback workbook tab 27 · Detection version The columns · the rows stay with the deployment
Detection key Logic version Effective from Version status search-language hash Supersedes Platform version ref Approved by Notes Detection registry 
