Application-level evidence
Record decisions and events directly from the application using REST, Python or TypeScript.
Best for:Explicit decision lifecycle instrumentation.INTEGRATION PATHS
Fit the evidence layer around the stack you already run.
LoopGrid keeps a provider-neutral evidence model while exposing several capture paths. Choose the least invasive integration that still captures the claim you need to verify.
01Agent / applicationmodel · runtime · workflow
02Capture adapterREST · SDK · OTLP · MCP
03LoopGrid workspaceappend-only signed evidence
04Export / verifierportable bundle · offline checks
AVAILABLE PATHS
Match the capture point to the evidence claim.
A simple application event and a system-of-record action do not need the same integration. Higher-risk claims should capture closer to the consequential action boundary.
Out-of-band capture
Accept OTLP/HTTP protobuf or JSON on /v1/traces, with optional gzip, then map compatible telemetry into the same evidence path.
Tool-action evidence
Capture the consequential tool request and downstream result when the evidence depends on an external state change.
Best for:Agent actions where “what actually happened” matters.Independent verification
Export a portable evidence bundle and verify captured integrity/provenance offline or gate CI with the published GitHub Action.
Best for:Customer, security, audit, release and investigation workflows.CURRENT SURFACES
One contract, multiple entry points.
The current public materials expose the core SDK/API and open-protocol paths. Provider/runtime adapters should translate into the same evidence contract rather than fragmenting the product.
SDK + APIRESTPythonTypeScript
TelemetryOpenTelemetryOTLP/HTTP protobuf + JSONgzip requests
Agent / tool boundaryMCPAction + outcome capture
Verification / CIOffline verifierGitHub ActionsSigner pinning
Current examplesOpenAIAnthropicLangGraph
AVAILABLE NOW · CI VERIFICATION
Verify exported evidence in GitHub Actions.
The public loopgrid-evidence-verify@v1.0.0 Action runs LoopGrid's offline verifier in CI and can pin an expected signer key. It verifies captured integrity/provenance; it does not prove decision correctness or capture completeness.
ADAPTER ROADMAP
Distribution adapters should remain thin.
Potential targets include Dify, MCP Registry packaging, n8n, Make, Zapier, OpenAI Agents, Google ADK, Microsoft Agent Framework, CrewAI, PydanticAI, AWS Bedrock and additional model/runtime providers. These are roadmap targets, not claims of completed production integrations.
TRUST BOUNDARY
Do not sign only what the agent tells you.
If the evidence claim is that an external action really occurred, capture the request and authoritative response at a boundary the agent cannot rewrite. Correlation, retries, idempotency and failure handling should remain explicit.
01Correlate
Use a durable decision/workflow ID across agent, approval and external systems.
02Capture
Record the consequential request and observed downstream result at the right boundary.
03Verify
Export evidence and check integrity/provenance independently using the expected signer identity.
DEVELOPER PATH
Get to one verified decision first.
Start locally, instrument one workflow, export the evidence, then decide whether a deeper adapter is justified.