KROG
🇳🇴

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.

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.