Concepts overview

Iqrar is the combination of five cryptographic primitives, designed so that integrity of committed facts is verifiable end-to-end without trusting Iqrar's infrastructure. Each primitive corresponds to an independent patent claim chain.

1. Foundation registry

A registry is a signed artifact listing every authority — regulators, the foundation itself — and their public keys. The registry is signed by a threshold of foundation root keys (initial v1: 1-of-1; pre-Provisional B: 3-of-5).

Authorities each have:

• Scope — the jurisdictions they are entitled to author rules for (DFSA: AE, AE-DIFC; ESMA: EU).
• Capabilities — what they may issue (rule_bundle, directive).
• A public key the SDK pins on first boot.

Once the SDK has pinned a registry, unsigned rules are refused. Verification is sticky.

The registry replaces the trust model where a single vendor can change rules unilaterally with a multi-party governance pattern where rule-authoring authority is structurally separate from infrastructure operation. This is patent claim §8.1 in combination with §5.2.

2. Signed rule bundles + runtime directives

Every rule update an agent receives is a signed bundle containing a ruleset (regulatory obligations, tier classifiers, principles) plus an optional list of directives — runtime instructions the regulator can issue without redeploying agents.

Directive types:

• verbosity — elevate audit detail (off / normal / debug).
• sample_rate — change what fraction of events are persisted in full.
• operational_pause — suspend a named capability for the directive's window.

Each directive carries:

• An issuer kid matching an authority in the pinned registry.
• A target (jurisdiction, agent ID, or capability set).
• A time window ({start, end?} in milliseconds).
• An action (one of the types above).

The SDK independently verifies every directive against the registry, refuses any whose scope does not encompass the agent's jurisdiction, and emits directive.received / directive.applied / directive.skipped / directive.rejected events into the audit chain so the SDK-side enforcement decision is itself recorded. Patent §8.1 full.

3. Per-event hash chain → Merkle tree → Sigstore Rekor

Every telemetry event the worker accepts is appended to its agent's per-agent tamper-evident hash chain:

entry_hash[n] = sha256( entry_hash[n-1] || event_hash[n] || seq[n] )

The chain is append-only by construction. Any tampering with a historical event invalidates every chain entry after it. Patent §8.3(a).

A cron task running every minute reads each agent's chain since their last commitment, computes an RFC 6962-style Merkle root over the entries, signs the root with a foundation key, and submits the signed STH (Signed Tree Head) to Sigstore Rekor — a public transparency log used by the open-source supply-chain world.

The Rekor entry URL is then returned in any inclusion-proof response, so a regulator can verify integrity against a log Iqrar does not control. Patent §8.3(b).

4. Source-boundary channel encryption

Telemetry events are not encrypted only in transit — they are encrypted at the SDK boundary, per recipient, before they enter Iqrar's routing infrastructure.

For each event the SDK:

1. Generates an ephemeral ECDH-P-256 keypair (forward secrecy per event).
2. Derives a per-recipient symmetric key via HKDF-SHA256.
3. Encrypts the payload with AES-256-GCM, once per recipient.
4. Posts the resulting EncryptedEvent envelope to /telemetry/channeled.

The worker stores ciphertext segments by recipient_kid and is structurally unable to decrypt — it has no recipient private keys. Operators retrieve their segments at /recipients/<kid>/events, regulators retrieve theirs at the same endpoint with their own kid.

Crucially, the SDK emits a channel.classified audit event for every channeled emission, recording which recipients each segment was addressed to. A downstream filtering attack — where the worker silently drops some recipients' segments — becomes detectable, because the regulator can compare what they received against what the SDK committed. Patent §8.2 full.

5. Predicate-scoped audit challenges

A regulator can issue a signed challenge containing a predicate over the agent population (jurisdiction, capability set, time window, action type) and a deterministic sampling rule.

The worker:

1. Verifies the challenge signature against the pinned registry.
2. Scope-checks the predicate against the issuer's recorded jurisdiction.
3. Resolves matching agents, loads their audit-chain entries within the window.
4. Applies a deterministic SHA-256-PRF sample the regulator can independently recompute.
5. Builds a Merkle inclusion proof for each sampled entry against the smallest STH that covers it.
6. Returns { proofs[], rekor_url } — every proof verifiable locally.

When the challenge is bound to a directive (via bound_directive_id), the response also includes the directive's own audit-chain lifecycle entries with inclusion proofs — so the regulator can verify directive application alongside the action records the directive shaped. Patent §8.3 full, including the sub-claim that the investigative chain is itself committed and verifiable.

How they compose

The five primitives compose into a single property: a regulator can verify, end-to-end, that:

1. The rules an agent follows are exactly the rules that authority signed.
2. Any runtime directive that authority issued reached the agent and was applied.
3. The agent's recorded actions during that directive's window are exactly the actions Iqrar's infrastructure has committed.
4. None of those records have been tampered with — any change invalidates the inclusion proof against the public Rekor log.
5. The regulator's own copy of the agent's telemetry, addressed to their channel, is a faithful subset of what the SDK committed.

Without trusting Iqrar's infrastructure. That is the design's central commitment.

Where this lives in the spec