Concepts / Assurance, readiness, and eligibility
Copy page as MarkdownJoin the sandbox waitlist
ConceptsEARLY ACCESS

Assurance, readiness, and eligibility

Three independent questions decide what an asset may become: how trustworthy is the data, is the asset legally ready, and who is allowed to hold it. All three must be true at once.

Why three and not one

v0.1 of this API answered all three with a single field. assurance_level: L2 unlocked PowerYield issuance, and readers drew the obvious conclusion: a signing chip is enough to issue a cash-flow asset.

It never was. A device signature proves exactly one thing — that a registered device submitted this reading and nobody altered it in transit. It does not prove the plant's title is clean, that the SPV may assign the revenue, that the PPA is valid and enforceable, that the offtaker actually pays, that the asset is not already pledged elsewhere, or that this product may be offered in the buyer's jurisdiction.

The legal gate existed all along — the human review behind projects:submit has always checked title and offtake — but it was implicit, and an implicit gate is one nobody can plan around. Three fields, each answering one question, is not more bureaucracy. It is the same bureaucracy, stated.

data_assuranceHow much the data can be trustedL0 · L1 · L2 · L3
asset_readinessWhether the asset is legally readydraft · technical_verified · legal_verified · investment_ready
compliance_statusWho may hold itdeclared per offering

Dimension one · data_assurance

data_assurance grades the data. It does not grade the asset. L3 on a plant with a defaulting offtaker is still L3 — an honest record of a bad situation.

LevelProvenanceProvesDoes not prove
L0Self-reported over the API.That someone submitted this number.Everything else.
L1Pulled from a manufacturer's cloud under OAuth, carrying that vendor's provenance signature.That the data came from a specific vendor cloud account.Whether the device was tampered with.
L2Signed inside the device by a key held in a secure element and never exported.That the data came from a registered device and was not altered in transit.Whether that device measures accurately, or whether the plant is yours.
L3L2, plus independent settlement-side evidence and periodic audit sampling.The above, and that it reconciles with an independent money-side record.Legal title, or eligibility to issue anywhere.

Dimension two · asset_readiness

StateMeansEstablished by
draftProject created, not submitted.The asset owner
technical_verifiedBaseline complete, devices trusted, generation data stands up.Automatic
legal_verifiedTitle, offtake contract, SPV structure, insurance, and permits verified.A licensed service partner, plus Arkreen review
investment_readyAll of the above, and the settlement rails and custody arrangements are in place.Review

This dimension is the one a signature cannot reach. It moves when a licensed partner signs an attestation about documents they actually read — see Reference / Service Partners — not when a meter behaves well for ninety days.

Dimension three · compliance_status

Eligibility attaches to the offering, not to the project. The same plant can be financed twice under two different sets of investor rules, in two jurisdictions, at the same time — which is why this was never a property of the asset.

Issuance gates

To issuedata_assuranceasset_readinessAREC / ART environmental attributes≥ L1≥ technical_verifiedPowerYield cash-flow units≥ L2= investment_readyStructured products / collateral= L3= investment_ready
⚠ Two conditions, not one

The most expensive misreading of v0.1 was treating L2 as sufficient to issue PowerYield. It is necessary and it is not sufficient. A project can sit at L3 for a year and still be unable to open an offering because its readiness never left technical_verified — and the error you will get is insufficient_readiness, not insufficient_assurance.

What we deliberately do not publish

We publish the inputs. We do not publish a grade. Arkreen is not a rating agency and will not become one — being both the issuance venue and the rating authority is a conflict the rest of finance already learned to separate.

External review asked for a fourth dimension: economic_risk, grading generation risk, counterparty risk, liquidity, and jurisdiction. We declined, and the reason is not modesty.

Everything such a grade would be built from is already published and free to read: GET /v1/risk/projects/{id} exists precisely so that rating agencies, lending protocols, and index providers can each build their own view. The moment we also publish the conclusion, we are marking the exposure we sell — and everyone downstream inherits our model whether they believe it or not.

Not a rating — a feed. Disagreeing with us should be cheap, and it stays cheap only if we never issue the number to disagree with.

Downgrade is provisional first

Protection is automatic. Correction is not the same thing as approval.

The downgrade fires without anyone deciding to let it. What follows — submitting evidence that a meter was swapped rather than tampered with, and having the level restored — is a process, and it should be. A system that cannot tell a firmware update from an attack, and has no way to be told, is not rigorous. It is just brittle.

The state machineTrigger fires→ assurance_state: provisional_downgrade automatic, immediate→ new issuance frozen automatic→ weight in every structured product set to 0→ existing positions and distributions never affected→ partner submits remediation evidence window: 14 days→ automatic re-check, or human review→ restored to restores_to ·or· confirmed_downgrade
Triggers · provisional_reason
Continuity gap beyond tolerancecontinuity_gapCounter regression inside a meter_epochcounter_regressionAnomaly unresolved past SLAanomaly_unresolvedAudit variance beyond toleranceaudit_varianceSettlement source stalesettlement_source_staleDevice key revokedkey_revoked

A meter swap registered through POST /v1/devices/{id}:meter-swap does not trigger a downgrade at all. A counter that goes backwards without one does — and that asymmetry is the whole design. Tell us before, and it is maintenance. Tell us after, and it is evidence you have to produce.

In the API

// GET https://sandbox.api.arkreen.com/v1/projects/prj_8fK2mQ
{
  "data_assurance": "L3",
  "asset_readiness": "investment_ready",
  "assurance_state": "active",
  "assurance_history": [
    { "level": "L2", "from": "2025-01-15", "to": "2025-04-02", "reason": "initial" },
    { "level": "L3", "from": "2025-04-02", "to": null,         "reason": "audit_passed" }
  ]
}
Filter by themGET /v1/offerings?data_assurance=L3&asset_readiness=investment_readyInspect the detailGET /v1/projects/{id}/assuranceAsk for an upgradePOST /v1/projects/{id}/assurance:request-upgradeContest a downgradePOST /v1/projects/{id}/assurance:submit-remediationSubscribe to changeassurance.upgraded · assurance.provisionally_downgraded · assurance.downgraded · assurance.restoredRead it on-chainAssetRegistry.dataAssurance(projectId) · AssetRegistry.assetReadiness(projectId)

Common misreadings

⚠ data_assurance is not a credit rating.

L3 says the data about a project is trustworthy. It says nothing about whether the offtaker will pay, whether the tariff is good, or whether the equipment was well chosen. A perfectly honest record of a failing plant is still L3.

⚠ asset_readiness is not a quality opinion either.

investment_ready means the documents exist, were checked by someone licensed to check them, and the money can physically move. It is a completeness statement, not a recommendation.

⚠ Neither is permanent.

Both are live properties recomputed continuously, not certificates issued once.

⚠ None of them gates reading.

Anyone can read an L0 draft project. These dimensions gate what the data can become, never who can look at it. And data_assurance is not a quality score for the hardware: a cheap inverter with a signing element reaches L2, a premium one without cannot.