DEVELOPERS

Start with the record.
Keep the contract explicit.

Explore the evidence model and integration boundaries before connecting a consequential workflow.

01 / EVIDENCE MODEL

A record a reviewer can follow.

A useful evidence record connects the source, context, policy and authoritative receipt reference. The example below is explanatory. It is not a published API request schema.

evidence-example.json

{
  "record_kind": "illustrative_example",
  "tenant_scope": "demo-workspace",
  "source": "Customer issue record",
  "context": [
    "Account tier",
    "Retrieval set",
    "Case history"
  ],
  "policy": "Support escalation v3.2",
  "receipt_reference": "demo_rct_7v2a\u2026e91c",
  "verification_status": "not_a_live_receipt"
}

Open interactive examples Download example

02 / RECORD FIELDS

Keep each reference meaningful.

Source: The material captured as evidence and the reference needed to inspect its origin.
Context: Retrieved material and configuration available to the recorded workflow.
Policy: The policy identifier or version associated with the event.
Receipt reference: An authoritative identifier returned by the evidence backend, never invented by a production frontend.
Tenant scope: The workspace identity enforced by the authenticated backend. A client-provided value does not authorize access.

03 / INTEGRATION BOUNDARIES

Identity before evidence.

PHIROK’s product architecture includes protected MCP and gRPC boundaries. Authentication, tenant scope and authoritative receipt handling are part of the integration contract.

Resolve identity from authenticated backend context.
Treat unsuccessful retention as a failure, not as a verified receipt.
Retrieve records by authoritative identifiers.
Keep source material and its verification context available.
Keep test fixtures separate from production evidence.

Before integrating

Obtain the endpoint, authentication requirements and versioned API contract for your deployment. This site does not publish or guess those details.

04 / EVALUATION

Make the acceptance criteria observable.

Retain → inspect
Write evidence, obtain an authoritative receipt and resolve it back to the retained record.
Retrieve → provenance
Confirm that search returns traceable evidence rather than generated substitutes.
Restart → recover
Verify retained state and receipt lookup across the recovery procedures for your deployment.
Tenant A → Tenant B
Check that one authenticated workspace cannot access another workspace’s evidence.
Failure → explicit outcome
Inspect behavior under invalid input, unavailable storage and unauthorized access.

Prepare an evaluation brief

05 / QUESTIONS

Questions, answered.

Does PHIROK generate answers?

No. PHIROK is presented as a verifiable memory and evidence platform. Its non-generative retrieval returns evidence for another system or reviewer to use.

Can a receipt prove what an AI was thinking?

A receipt can bind recorded evidence and context. It does not reveal a model’s private internal reasoning or establish that every available input causally influenced an output.

Are commercial production embeddings available?

The current semantic layer is described with deterministic test fixtures. This site does not advertise commercial production embeddings as an available capability.

Where can an agent read the site?

The main content is present in plain HTML. A concise Markdown overview and full technical brief provide an additional reading format. They do not replace the deployment’s API documentation.

Start with the record.Keep the contract explicit.