Verify by DSEO Marketing
EN ES
API

A local API. It runs on your machine, when you start it.

Fifty-three operations on 127.0.0.1:4177, serving the same data the console shows and the terminal client uses. The document below is generated from the routes the server registers, so it cannot drift away from what actually answers.

Nothing is hosted. Nothing is deployed. No endpoint of this product is reachable from the internet, and running it locally is not the same as it being audited, certified or published.

Implementedlocal and loopback only
01 Endpoints
MethodPathPurpose
POST/v1/artifacts/inspectRegister an artifact and receive its canonical identity.
POST/v1/assessmentsSubmit a bundle, authority, policy and pins for assessment.
GET/v1/assessments/{id}Read a previously produced assessment result.
GET/v1/assessments/{id}/evidenceRead the evidence graph consumed by an assessment.
GET/v1/assessments/{id}/receiptRead the receipt bound to an assessment, if one exists.

Read the full OpenAPI document →

02 What the response separates 
{
        "assessment_id": "asmt_...",
        "record_valid": true,
        "security_assessment_status": "FAIL",
        "release_authority": false,
        "errors": [ { "code": "...", "message": "..." } ],
        "evidence_ref": "/v1/assessments/{id}/evidence",
        "receipt_ref": "/v1/assessments/{id}/receipt"
      }
03 Design decisions
  • Idempotency: assessment submission accepts an idempotency key; retried submissions return the original result.
  • Request IDs: every response carries a request id for correlation with logs.
  • Content hashes: every object reference includes its sha256, never only a name.
  • Policy references: a policy is referenced by digest, matching what the kernel actually pins.
  • Error model: errors use the same finite diagnostic codes the reference kernel returns.
04 The mechanism

How an integration would work.

How this works

  1. 01

    A caller submits a record and its pins

    The pins are four digests supplied separately: what the record, policy, authority and artifact are each expected to be.

  2. 02

    The service evaluates and answers on three axes

    Whether the record is interpretable, what the evidence shows, and that release authority is false — pinned to false in the contract itself.

  3. 03

    Evidence and receipts are fetched separately

    The answer carries references rather than everything at once, so a caller can decide how deep to look.

  4. 04

    The calling system decides what to do

    The API describes an assessment. Acting on it belongs to whatever holds authority over the system in question.

Step by step

  1. Open the full OpenAPI document linked above.

    You will see five endpoints, their request and response shapes, and an error model.

    That means enough to plan an integration, or to have your own engineers judge it.

  2. Search that document for release_authority.

    You will see it appears with enum: [false].

    That means the contract forbids any response from granting permission. This is a design guarantee, not a convention.

  3. Look at the servers section.

    You will see localhost, and a future host marked x-future-placeholder.

    That means no live address is being implied. Nothing here is running.