TTTPS Proof-of-Time Explorer

A Layer 7 AI control-plane primitive: cryptographic proof-of-time receipts for LLM and agent outputs. Any framework's output gets hashed, sealed with a signed timestamp, and independently verifiable after the fact — without ever blocking or altering the original response.
8.6ms
measured warm p50 for a full POST /v1/anchor round trip against the live public API (p90 12.0ms, n=30). Cold p50 33.2ms / p90 45.1ms, n=30. 61/61 HTTP 200. Client in the same region; your network path will differ.
Fail-open, always
a sealing failure never blocks or mutates your LLM response — it degrades to a status flag. Demonstrated by blocking Roughtime UDP until the quorum broke: /v1/anchor stayed 3/3 HTTP 200 and time_source downgraded to local rather than lying.
8 frameworks
LangChain · LiteLLM · LlamaIndex · smolagents · vLLM · Ollama · DeepEval · Ragas. Which are installable today is listed on the API page, not duplicated here.
Endpoint-by-endpoint spec, every integration's real install command, and which ones are PyPI-published vs. locally verified — kept in sync with what's actually shipped, not aspirational.

How it fits into your stack

Your app / agent
LangChain, LiteLLM, LlamaIndex, smolagents, vLLM, or Ollama
OpenTTT integration
sha256(output) computed locally, sent async, fail-open
KPP Provenance API
kpp.kenosian.com — signs + timestamps the hash
Verifiable receipt
receipt_id + signature, independently re-checkable anytime
Your original LLM/agent response is never touched or delayed — only its hash leaves your process, asynchronously, and only a receipt comes back.

Quickstart — pick your framework

Every integration attaches a cryptographic audit-trail timestamp. None of them certify legal or regulatory compliance (EU AI Act, FDA, etc.) on their own.
PyPI: v0.3.0 published
pip install langchain-openttt installs the published v0.3.0 package, which ships both TTTPSTimestampCallbackHandler (internal PoT server) and TTTPSTimestampCallbackHandlerKPPLive (this public self-serve API) — verified importable from the live PyPI wheel in an isolated venv. It is also registered in LangChain's own docs repo rather than mentioned by a third party: langchain-ai/docs #5257 adds it to the integrations YAML and is merged into the LangChain External Integrations Registry.
pip install langchain-openttt   # v0.3.0

import os
os.environ["KPP_API_KEY"] = "kpp_prov_..."  # mint free: POST https://kpp.kenosian.com/v1/keys

from langchain_openttt import TTTPSTimestampCallbackHandlerKPPLive

resp = llm.invoke("hi", config={"callbacks": [TTTPSTimestampCallbackHandlerKPPLive()]})
# resp.generation_info["tttps_receipt"]
# -> {"status": "ok", "receipt_id": "...", "receipt": "...", "time": "...", ...}
PyPI: v0.1.0 published
Docs recipe (inline CustomLogger) shipped upstream via BerriAI/litellm-docs #760 (docs/observability/tttps_provenance.md, open).
pip install litellm-openttt   # v0.1.0

import litellm
from litellm_openttt import TTTPSTimestampLoggerKPPLive

litellm.callbacks = [TTTPSTimestampLoggerKPPLive()]

resp = litellm.completion(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "hi"}],
)
print(resp.tttps_receipt)
# {"status": "ok", "receipt_id": "...", "receipt": "...", "time": "...", ...}
PyPI: v0.1.0 published
No upstream PR here yet. run-llama/llama_index's own CONTRIBUTING.md states new integration packages aren't accepted into the monorepo and must already be published to PyPI independently first. That precondition is now met, so a docs PR is the next step rather than a blocked one.
pip install llamaindex-openttt   # v0.1.0

from llama_index.core import Settings
from llama_index.core.callbacks import CallbackManager
from llamaindex_openttt import TTTPSTimestampCallbackHandlerKPPLive

Settings.callback_manager = CallbackManager([TTTPSTimestampCallbackHandlerKPPLive()])

resp = llm.complete("hi")
print(resp.additional_kwargs["tttps_receipt"])
# {"status": "ok", "receipt_id": "...", "receipt": "...", "time": "...", ...}
PyPI: v0.1.0 published
Example shipped upstream via huggingface/smolagents #2597 (examples/mcp_tttps_provenance.py, open). Full walkthrough in the Show and tell discussion #2600. smolagents can also reach the same tools over MCP with no adapter package at all.
pip install smolagents-openttt   # v0.1.0

from smolagents import CodeAgent
from smolagents_openttt import ttts_pot_step_callback_kpp_live

agent = CodeAgent(
    tools=[],
    model=your_model,
    step_callbacks=[ttts_pot_step_callback_kpp_live],
)
result = agent.run("your task")

for step in agent.memory.steps:
    print(getattr(step, "tttps_receipt", None))
    # {"status": "ok", "receipt_id": "...", "receipt": "...", "time": "...", ...}
PyPI: v0.1.0 published
Registers via vLLM's official --middleware flag (confirmed live against vLLM's own build_app() with a real server and a completed /v1/completions round trip). The example shipped upstream via vllm-project/vllm #50998 (examples/observability/tttps/, open) calls the public kpp.kenosian.com API, so external readers can reproduce it.
pip install vllm-openttt   # v0.1.0

export KPP_API_KEY=kpp_prov_...   # mint free: POST https://kpp.kenosian.com/v1/keys
vllm serve facebook/opt-125m \
  --middleware vllm_openttt.TTTPSMiddleware

# curl http://localhost:8000/v1/completions ...
# -> response header: X-TTTPS-Receipt: {"status": "ok", "receipt_id": "...", "receipt": "...", ...}
PyPI: v0.1.0 published
Ollama has no plugin/middleware extension point (confirmed by reading server/routes.go), so this is a small reverse proxy in front of it. It already targets the public kpp.kenosian.com API. Both non-streaming and streaming (NDJSON) responses are supported — streaming gets a receipt attached to its final done:true line only, with zero added per-token latency. Ollama's README does have a real “Community Integrations” list open to PRs, but this proxy isn't in its own public repo yet, so there's nothing citable to link there yet — tracked, not forgotten.
KPP_API_KEY=kpp_prov_... python ollama_proxy.py --port 11435
# point your Ollama client at localhost:11435 instead of 11434

curl localhost:11435/api/generate -d '{"model":"qwen2.5:0.5b","prompt":"hi","stream":false}'
# -> ollama's normal JSON, plus a "tttps_receipt" field and
#    X-TTTPS-Receipt / X-TTTPS-Status response headers

Live Inspector — try it yourself, right now

Live demo of a proposal specification, not a ratified standard.
This section calls the real, public /v1/anchor and /v1/verify endpoints directly from your browser — nothing here is simulated, and there is no backend server for this demo other than your own browser and the API itself, served from kpp.kenosian.com.

What a receipt is, and is not: a receipt cryptographically attests when a content hash was sealed, its order relative to other seals, and that it is tamper-evident after the fact. It does not attest that the content itself is correct, true, or valid — that is a separate, orthogonal claim TTTPS does not make.

The text you type below is hashed with sha256 in your own browser before anything is sent anywhere. Only the hash ever leaves your machine.