Gravit Verifier is an open-source reference implementation (Python and Rust) that decides what a claim may be called (Verified Fact, Probabilistic Assessment or Speculative Claim) from signed, indepen
翻译准备中
其他PHP · PythonGitHub @gravit-open-network-foundation在线运营者未确认
试用过了吗? 点一下就好,无需登录。
尚未检测到更新。GitHub 发布版本后会显示在这里。
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权,自行管理介绍,无需管理员批准。
登录并生成验证文件,在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件,即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录,将前往登录页面。登录后请回到此处,再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify,即可验证所有权并自行管理介绍。
一分钟完成验证Hosted Gravit Verifier API: signed, hash-chained receipts for every decision, verifiable offline; Python and TypeScript clients
翻译准备中
取自仓库 README
正在加载完整 README。
查看完整 README ↗The hosted API behind gravitverifier.space: the open-source Gravit Verifier (pinned version) behind API keys, with a signed, hash-chained receipt for every decision that anyone can check offline.
| Part | What |
|---|---|
public/ | PHP router, served at /api/v1/ |
private/ | outside the web root: lib.php (keys, plans, receipts), worker.py (runs the verifier), admin.php, data/ |
sdk/python | gravit-verifier-client: API calls plus offline verify_response and verify_export |
sdk/typescript | gravit-verifier-client: API calls |
tests/test_api.py | end-to-end test: decisions equal the verifier's golden vectors byte for byte, receipts and export verify, tampering is detected |
| Endpoint | |
|---|---|
POST /api/v1/verify | body {"artifact": {...}, "use_test_registry": true, "registry": optional} → {result, receipt, signature, entry_hash} |
GET /api/v1/decisions?limit= | your decision history |
GET /api/v1/decisions/{decision_id} | one decision with its receipt |
GET /api/v1/export?from_seq= | all receipts, signed and hash-chained, for your auditor |
GET /api/v1/usage | plan and monthly usage |
GET /api/v1/service-key | the service's Ed25519 public key (no key needed) |
POST /api/v1/gate | Capability Gate: {capability, action or action_hash, policy, decision_id?, overrides?} → fail-closed state SAFE / FRONTIER / UNSAFE / UNKNOWN with a receipt in the same chain |
GET /api/v1/status | health and component versions (no key needed) |
GET /api/v1/log/proof/{entry_hash} | inclusion proof of your receipt in the public receipt log, with the signed tree head; check offline with verify_log_proof |
GET /api/v1/openapi.json | OpenAPI 3.1 description of this API (no key needed) |
Next to the decision, the result carries a Graviteron: how strongly the counted evidence supports the
claim (expected) and how much evidence stands behind it (uncertainty), computed with
graviteron.evidence (vendored in
private/graviteron_evidence). Every operator is trusted equally for now, so its calibration is
not yet established; the decision itself is unchanged.
The request body is passed to the verifier byte for byte, so signed numbers keep their exact form.
The result in the response is the verifier's canonical JSON; result_sha256 in the receipt covers it.
Early service (October 2026). Plans and prices are planned, not yet sold. The bundled registry and trust root are test keys from the verifier's test suite; bring your own registry for real use.
Once a day private/publish_log.py builds an RFC 9162 Merkle tree over the entry hashes of all
receipts of all accounts, signs the tree head with the service key and has it timestamped by three
independent RFC 3161 authorities (DigiCert, Sectigo, GlobalSign; the time counts as a Verified Fact
when at least two agree). Heads are public at https://gravitverifier.space/log/latest.json and
/log/heads/<size>.json. So we cannot quietly remove or change a receipt we issued: every later head
would show it. Merkle tree and anchors are vendored from
History Keeper.
php admin.php delete <email> erases what identifies a person: the email, the API keys and the stored
results. The receipts stay: they are leaves of the public log and hold no personal data (account id,
hashes, states). Their signatures still verify; result_sha256 then refers to a result that was erased.
Remove the address from the waitlist file as well.
/v1/gate answers one question for an AI agent: may this capability be used for this exact action?
The policy lists allowed, frontier and forbidden capabilities; anything else is UNKNOWN and blocked.
A frontier capability is permitted only with decision_id of a decision from /v1/verify in your
account that is a Verified Fact with status SUCCESS and whose artifact_id equals the action hash
(SHA3-256 of the canonical action, returned as action_hash). Specification and tests:
capability-gate.
Licence: Apache-2.0.