KROG
🇳🇴

Product

KROG is the competency graph for professional knowledge.

KROG structures professional competence so people, organisations and machines can determine who can do what, at what level, and on what evidence: Person → Role → Competence → Level → Evidence → Assessment → Credential. Law and AI governance are the first domain implemented on this architecture, not its boundary. For regulated work, a connected layer — jural state, authority, agents and records — answers what an actor is permitted to do. Everything below is on this one page: the systems, the records layer, the agents, the engine and the process from need to issued credential.

Two connected systems

The Competency Graph is the core of KROG. The Jural State system is a connected layer for regulated work. They are not the same graph, but they can be evaluated together where required.

Competency Graph

Status: Beta

Who can do what, at what level, supported by what evidence.

  1. Person
  2. Role
  3. Competence
  4. Level
  5. Evidence
  6. Assessment
  7. Credential

Jural State

Status: Roadmap

Who may do what, under which rule and authority.

  1. Rule
  2. Jural state
  3. Authority
  4. Action
  5. Record

How the two systems connect

  1. Competence
  2. Authority
  3. Action
  4. Record

The connection applies where an action requires both competence and legal authority.

Competence and authority are different. A person or agent may have the competence to perform an activity without having the legal authority to perform it in a particular context. KROG models these separately so they can be evaluated together where required.

What is jural state

A living model of where you stand.

Your jural state is the complete set of legal relations you hold at this moment with every counterparty, authority and agent — modelled as parties (nodes) and jural positions (edges) that change over time. Four positions — claim, liberty, power and immunity — replace vague legal context with a precise vocabulary.

Not practice areas. A living model of where you stand.

Example

From specification to state

Same DPS, two perspectives. Each party sees their own jural state — the claims, liberties, powers and immunities they hold toward the counterparty.

Perspective 1

Your jural state as Data Subject — toward the Controller

Subscriber(Data Subject)Controller▲ power↔ liability◆ claim↔ duty

Hover or focus an edge to see what each jural position means.

1. DPS

Facts

Email Newsletter

See full specification
ID
6d79e35089c96073
Purpose
Direct Marketing
Data
Email address, name (optional)
Actions
Collect, store, use, transfer
Roles
Data Controller
Sensitive
No

2. Rule

krogrules.com

  • GDPR Art. 6(1)(a)

    Consent grants the Controller a legal basis to process — a permission, not a competence. The Data Subject retains the competence (power) to withdraw consent.

    Source ↗

  • GDPR Art. 13

    The Controller has a duty (the Data Subject has a claim) to provide information at the point of collection.

    Source ↗

3. Jural state

Positions

  • Subscriber ─claim→ ControllerClaim to information (Art. 13) · Controller: duty
  • Subscriber ─power→ ControllerPower to withdraw consent (Art. 7(3)) · Controller: liability
  • Controller ─liberty→ SubscriberLiberty to process under consent (Art. 6(1)(a))
Active pathDPSRulepositionState

The DPS describes. The rule subsumes. The jural state is what actually holds.

The records layer

Verifiable, not merely asserted.

Every change of position is recorded — append-only, cryptographically signed, with provenance and integrity proofs. Records use open standards so they remain meaningful outside our platform.

  • Consent record

    Permission given by a data subject, captured with purpose and basis.

    built to ISO 27560

  • Contract record

    Agreed terms between parties, with provenance of every change.

    PROV-O

  • Authorisation record

    Granted authority — who may act, for what, within what bounds.

    ODRL · VC

  • Right-exercise record

    An act invoking a held right, signed and time-stamped.

    PROV-O

  • Confirmation / receipt

    Signed acknowledgement that an event was received and accepted.

    built to ISO 27560

Consent is one record type among many. The records layer covers the full lifecycle of jural positions, not only personal-data permissions.

Built for agents

Records readable — and actionable — by machines.

Records are machine-readable across open vocabularies: DPV, ODRL, PROV-O, and Verifiable Credentials. Authorised AI agents can read the jural state and act within the authority they have been granted — auditably.

Your records are readable and actionable by machines — within bounds you set.

Available todayConsent API
Example POST request to the KROG Consent API recording a consent event, returning an ISO 27560-shaped consent receipt.
POST /v1/consent/records
Content-Type: application/json

{
  "data_subject":  "sub_8f3c1a",
  "controller":    "krog.example/controller/acme",
  "purposes":      ["analytics.product_usage"],
  "legal_basis":   "consent",
  "consent_status":"given",
  "policy_uri":    "https://acme.example/privacy#v3"
}
View response
→ 201 Created
{
  "receipt_id":     "rcpt_01HV9Z…",
  "data_subject":   "sub_8f3c1a",
  "controller":     "krog.example/controller/acme",
  "purposes":       ["analytics.product_usage"],
  "legal_basis":    "consent",
  "consent_status": "given",
  "timestamp":      "2026-06-16T09:41:22Z",
  "signature":      "ed25519:…"
}

Consent infrastructure powered by Signatu

On our roadmapJural-state query

In the next stage, authorised agents will query the full jural state and receive a decision of permit · deny · null.

null means the act is competence-invalid — outside the actor's authority (ultra vires). That distinction, between an act that is forbidden and an act that has no legal effect at all, is what separates jural-state querying from a plain policy engine.

A two-layer engine

Conduct, then competence.

We don't only track what parties may do (conduct). We validate who holds the power to change a position and whether the act is valid (competence) — before computing the result. The difference shows up exactly where ordinary policy engines fail silently.

  • Breach

    Unlawful but effective.

    The act took effect; a duty was violated. Liability follows.

    A controller keeps processing data after a consent is withdrawn. The act has legal effect — the processing happened — but it is unlawful, and liability follows.

  • Ultra vires

    Outside authority, void.

    The actor lacked the competence to perform the act. The act has no legal effect.

    An AI agent authorised only to read case files attempts to sign a contract on the client's behalf. The act is outside its granted authority, so it is void — it never legally happened.

  • Disability

    No power, void.

    The actor never held the power in question. The act cannot land.

    A party with no mandate purports to waive a right they do not hold. They lack the power to change that position, so the waiver has no legal effect.

Breach is a question of conduct — the act counts, but it is wrong. Ultra vires and disability are questions of competence — the act does not count at all. KROG validates competence before it computes conduct.

How we work

Lawyers as Legal Engineers.

A four-step flow from specification to running compliance to agent-actionable tasks.

  1. Step 01

    Write a DPS

    Legal Engineers describe data activities in a Data Processing Specification — the single source of truth.

  2. Step 02

    Generate compliance documents

    Privacy notices, ROPA entries, DPIA inputs and contract clauses are derived from the DPS.

  3. Step 03

    Generate consent requests

    Requests are issued and recorded through the Consent API, with receipts built to ISO 27560.

  4. Step 04

    Generate agent task descriptions

    Machine-readable task briefs tell authorised AI agents what they may do, and within what bounds.

One specification, one state.

Same pattern as above — but here against the EU AI Act. Each Article 10 obligation is expressed as a state you can query.

Context

Personal data used to train a high-risk AI system

Data governance state (live) — EU AI Act, Article 10

Governance states

  • Data availability & quantityArt. 10(2)(e)Sufficient
  • Data suitabilityArt. 10(2)(e)Partial
  • Relevance & representativenessArt. 10(3)Sufficient
  • Error-freeness & completenessArt. 10(3)Partial
  • Contextual / geographic suitabilityArt. 10(4)Unknown
  • Bias examination & mitigationArt. 10(2)(f)–(g)Sufficient
  • Data gaps identified & addressedArt. 10(2)(h)Not met

EU AI Act Art. 10 documentation status for each high-risk AI system under your responsibility as provider.

Because each obligation is expressed against governed vocabularies, its state is a query — not a reconstruction. That is what an auditor, and an AI agent, can both read.

One worked example

The same object, through the whole chain.

Process, Records, Engine and Agents do not each describe a different example. They describe different stages of the same object: one consent under the Email Newsletter specification.

Object: Consent · sub_8f3c1a · DPS Email Newsletter (6d79e35089c96073)

  1. DPS
  2. Applicable rule
  3. Jural stateStatus: Roadmap
  4. AuthorityStatus: Roadmap
  5. Agent actionStatus: Roadmap
  6. Record
This page

DPS

Status: Live

The facts of the processing, written once.

Legal Engineers write the Email Newsletter specification: purpose (direct marketing), data (email address, name optional), actions (collect, store, use, transfer) and role (data controller). Everything downstream reads this one description.

Next stage →Status: BetaApplicable ruleThe rules that subsume the facts.

Stages labelled Roadmap are designed, not operational today. They are never described in the present tense.

Consent is the first record type. The same pattern — specification, rule, queryable state — extends to AI Act data governance, as above.

Available now

Start with consent.

We sell DPS and Consent Management today — built to ISO 27560 and ISO 29184, with verifiable consent receipts and full provenance from day one.