Back to HomepageGranullo Architecture

Architecture

How intent becomes governed before money moves

Granullo transforms plain-language intent into a governed structure of commitments, evidence requirements, verification rules, and settlement readiness. No money moves until every declared condition is independently verified. The architecture exists to prevent money from moving on ambiguity.

The governing path

Every program passes through four structural phases. At each phase, the system evaluates what enters, what it creates, and what can block progression.

IntentCommitmentVerificationSettlement

Intent

Enters

Natural-language description of what money should do

Creates

Structured intent record with declared purpose, parties, and constraints

Evaluates

Completeness of declaration — are all required fields present?

Blocks progression when

Ambiguous purpose, missing parties, undefined constraints

Commitment

Enters

Validated intent record

Creates

Bound commitment with conditions, evidence requirements, and verification rules

Evaluates

Structural integrity — are conditions specific, measurable, and independently verifiable?

Blocks progression when

Vague conditions, unverifiable requirements, single-actor override paths

Verification

Enters

Evidence submitted against bound conditions

Creates

Verification state for each condition — met, unmet, or contested

Evaluates

Evidence validity — does submitted proof satisfy the declared requirement?

Blocks progression when

Missing evidence, expired timestamps, conflicting submissions, failed cross-checks

Settlement

Enters

Fully verified commitment with 100% integrity score

Creates

Settlement release signal to external banking infrastructure

Evaluates

Final state check — are all conditions met, all rules satisfied, all parties confirmed?

Blocks progression when

Any unmet condition, any ambiguity flag, any contested evidence

What Granullo actually produces

Granullo is not abstract infrastructure. For every governed program, the system produces concrete, auditable artifacts that determine whether money is allowed to move.

Governed commitment records—Immutable, timestamped records of every commitment with full provenance
Structured conditions—Each condition is independently verifiable with defined evidence requirements
Required evidence definitions—Explicit specifications of what proof satisfies each condition
Rule evaluation states—Deterministic results of applying verification rules to submitted evidence
Integrity signals—Real-time scoring of commitment health based on verified vs. unmet conditions
Audit trails—Complete, append-only logs of every action, submission, and state transition
Settlement readiness states—Binary determination: the commitment is either ready for external settlement or it is not

Commitment object model

Every governed program is represented internally as a commitment object. This is the canonical structure that the system evaluates, tracks, and uses to determine settlement readiness.

program
program_idstring
Unique identifier for the governed program
intentstring
Natural-language declaration of what money is supposed to do
commitmentobject
Amount, frequency, and parties bound to the commitment
conditionsarray
Structural requirements that must be satisfied before settlement
required_evidencearray
Evidence specifications attached to each condition
verification_rulesarray
Deterministic rules governing how evidence is evaluated
current_stateenum
BLOCKED | PARTIAL | VALIDATED | SETTLEMENT_RELEASED
integrity_scorenumber
Percentage of conditions verified (0–100)
ambiguity_flagsarray
Active flags indicating unresolved ambiguity or missing evidence
audit_logarray
Append-only record of every state transition, action, and submission

How commitments move through the system

BLOCKED is the default state. Every commitment begins there and remains there until every condition is verified with evidence. The system never guesses, never assumes, and never progresses on incomplete information.

Registered

Commitment created from validated intent. All conditions bound. State: BLOCKED.

Awaiting Evidence

System tracks which conditions have evidence and which do not. No progress without proof.

Evidence Received

Evidence submitted against one or more conditions. Each submission timestamped and recorded.

Rule Evaluation

Verification rules applied to submitted evidence. Deterministic — same evidence, same result.

Verified or Blocked

Condition marked as met (evidence sufficient) or remains unmet (evidence insufficient or contested).

Settlement Ready

All conditions verified. Integrity score: 100%. Commitment released to external banking rails.

Evidence and verification layer

This is where ambiguity gets surfaced. Evidence is not optional metadata — it is the mechanism that determines whether a condition is satisfied and whether money is allowed to move.

What counts as evidence

Any timestamped, attributable artifact that directly addresses a declared condition. Documents, records, sensor data, attestations, cross-referenced entries. The type is defined at condition binding — not at submission time.

How evidence attaches

Evidence is submitted against a specific condition within a specific commitment. It cannot be generalized across conditions. Each submission is recorded with timestamp, source, and hash.

How rules are evaluated

Verification rules are deterministic. ALL requires every condition to be met. TEMPORAL checks evidence recency. MULTI_PARTY prevents single-actor override. FAIL_CLOSED halts on any ambiguity. Same evidence always produces the same result.

Why the system cannot proceed without proof

Missing evidence is not a warning — it is a structural block. The system cannot infer, assume, or approximate. If proof is absent, the condition is unmet, the commitment is blocked, and settlement cannot occur.

Fail-closed architecture

The system is designed to prevent money from moving when there is insufficient evidence for it to move. This is not a safety feature — it is the core design principle.

Default state: BLOCKED

Every commitment begins blocked. The system does not assume progress. It does not auto-approve. It does not time out into approval. Blocked means: the evidence required to satisfy the declared conditions has not been provided.

Incomplete conditions stop progression immediately
Ambiguity in evidence lowers integrity score and surfaces flags
Contested evidence reverts affected conditions to unmet
The system never pretends certainty it does not have
Silence is treated as absence of evidence, not as consent

External settlement boundary

This boundary is absolute. Granullo's responsibility ends at validation. Settlement is always external.

Granullo governance layer

Validates commitment against declared conditions
Evaluates evidence against verification rules
Produces integrity scores and settlement readiness
Records full audit trail of every state transition
Settlement boundary

External execution layer

Banks hold custody of funds at all times
Payment rails execute the actual transfer
Treasury systems manage fund allocation
Settlement infrastructure handles finality

Granullo does not hold funds. Granullo does not execute payments. Granullo determines whether a program is ready for settlement.

Intelligence layer

The intelligence layer does not make decisions. It surfaces information that makes the state of commitments legible to operators. It explains why things are blocked and what would unblock them.

Incomplete intent detection

When a program declaration is missing required fields, undefined on scope, or ambiguous on parties — the system identifies the gap before conditions can be bound.

Missing evidence identification

For every condition, the system knows what evidence is required, what has been submitted, and what is still missing. This is surfaced in real-time to all authorized parties.

Ambiguity surfacing

When submitted evidence is unclear, contradictory, or insufficient — the system flags the ambiguity. It does not resolve it. It makes it visible and halts progression.

Blocked commitment explanation

For every blocked commitment, the system explains exactly why it is blocked: which conditions are unmet, which evidence is missing, which rules are failing.

System relationships

Inside every governed program, these entities are structurally connected. They cannot be separated, individually modified, or silently removed.

Actors—Parties bound to a commitment — declarers, verifiers, beneficiaries, authorizers
Commitments—Governed objects with bound conditions, evidence requirements, and verification rules
Evidence—Timestamped proof submitted against specific conditions within a commitment
Rules—Deterministic evaluation criteria applied to evidence — ALL, TEMPORAL, MULTI_PARTY, FAIL_CLOSED
Outcomes—Settlement readiness states derived from rule evaluation — never from discretion

Structural relationship graph

ActorsdeclareCommitmentswhich requireEvidenceevaluated byRulesproducingOutcomes

Operating principles

These are not guidelines. They are structural constraints enforced at every layer of the system. They cannot be configured away.

Fail-closed by default

When evidence is incomplete, ambiguous, or contested — the system halts. No money moves forward.

Ambiguity must be surfaced, not hidden

The system does not resolve uncertainty. It makes uncertainty visible and prevents progression.

Evidence before progression

No condition can be marked as met without independently verifiable proof. No exceptions.

Settlement remains external

Granullo determines readiness. Banks, payment rails, and treasury systems execute settlement.

No silent degradation

Every state change, every flag, every contested evidence is recorded. Nothing happens invisibly.

Governed paths are auditable

Any actor with access can trace the full path from intent to outcome. The trail is always complete.

Granullo does not move money.

It ensures money is only allowed to move when intent has become verifiable, governed, and externally ready for settlement.

Drag me for clarity