Documentation / v0.5.3 beta

From first install
to a verified action.

Start with the local demo, then provision identities and an executor for your integration.

Python 3.10+Self-hostedMIT licensed

01 / Install

Install the Python package.

Use Python 3.10 or newer. A virtual environment keeps the installation separate from your other projects.

Terminal
python -m venv .venv
# macOS / Linux
source .venv/bin/activate
# Windows PowerShell
# .venv\Scripts\Activate.ps1
python -m pip install tempus-ddb
tempus --help

Download the package from PyPI or inspect the artifacts on GitHub Releases. For source development, follow CONTRIBUTING.md.

02 / First verification

Run the local security demo.

With the package installed, clone the release source to get its examples. This demo uses a simulated downstream API and temporary local state.

Terminal
git clone --branch v0.5.3 --depth 1 https://github.com/elbuilder77/tempus-ddb.git
cd tempus-ddb
python examples/commercial_demo.py
What to look for

An authorized execution and a verified trace, plus rejected bypass, replay, expired-permit, tamper and cross-tenant attempts. The local simulation does not require a real GitHub token.

Prefer to explore without installing? Verify the browser sample.

03 / Request flow

Four steps. Separate responsibilities.

  1. Sign the intent. The requesting agent signs the exact action, resource, input and idempotency key.
  2. Evaluate policy. Tempus checks identity and policy, then returns ALLOWED or BLOCKED.
  3. Execute through the boundary. The isolated executor verifies the permit, consumes it once and calls the external service.
  4. Verify the receipt. The executor signs its outcome; the gate records linked evidence for later inspection.

The gate and executor remain trusted components. A signature verifies who signed an outcome; it does not make an external event independently observable.

04 / Provisioning

Establish the executor boundary.

Run setup in a separate working directory for your integration. These commands create local development keys and register the two identities; they do not yet configure a production deployment.

Terminal
tempus init
tempus keygen --output agent.keys.json
tempus keygen --output executor.keys.json
tempus register-agent --alias demo-agent --agent-keyfile agent.keys.json --metadata '{"tenant_id":"acme"}'
tempus register-agent --alias demo-executor --agent-keyfile executor.keys.json --metadata '{"tenant_id":"acme"}'
tempus doctor --json
tempus conformance --signer

Next, install a signed policy for your tenant, identities, supported action, resource and executor. See the configuration examples and DevOps blueprint for the complete setup.

Packaged executor commands
ExecutorSupported actions
tempus-github-executorCreate issues and pull requests
tempus-http-executorHTTPS POST, PUT and webhooks
tempus-slack-executorMessages and alerts
tempus-payment-executorReference payment adapter; mock transport included

Use each command's --help for its required permit, gate, tenant and executor options. Keep real downstream credentials in the executor environment. For workload signing, read the Vault Transit guide.

05 / MCP connection

Expose the autonomous tool surface.

After provisioning, add Tempus to your MCP client's configuration. Replace the absolute paths below with the database and gate key created during setup.

MCP configuration · JSON
{
  "mcpServers": {
    "tempus": {
      "command": "tempus",
      "args": ["mcp", "start"],
      "env": {
        "TEMPUS_MODE": "autonomous",
        "TEMPUS_GATE_KEYFILE": "/absolute/path/keys.json",
        "TEMPUS_DB_PATH": "/absolute/path/tempus.db"
      }
    }
  }
}

The client must be able to find the installed tempus executable. The default tools accept signed payloads; connecting the server does not sign requests or route every other tool automatically.

Claude / Cursor recipe ↗ · All framework recipes ↗

Reference / Contracts

Versioned evidence schemas.

Core protocol schemas
EvidenceSchema
Agent intenttempus.action-intent.v1
Signed permittempus.authorization-receipt.v1
Executor outcometempus.action-outcome.v1
Execution receipttempus.execution-receipt.v1
Complete tracetempus.action-trace.v1
Verification resulttempus.trace-verification.v1
Event stream itemtempus.event-stream-event.v1
Signed checkpointtempus.checkpoint.v1
Checkpoint verificationtempus.checkpoint-verification.v1

Read the compatibility policy before upgrading a deployed integration.

Reference / Audit

Inspect and verify a real trace.

Use the action ID returned by your runtime. Run these commands against the corresponding gate database.

Terminal
tempus trace --action-id <action-id>
tempus verify-trace --action-id <action-id>
tempus list-agents
tempus list-policies
tempus identity-events
Verified does not mean succeeded.

A failed execution can have authentic, correctly linked evidence. Verification and business outcome are separate results.

Reference / Durability

Retain checkpoints independently.

Create a signed checkpoint and export the event stream. Store trusted checkpoints outside the database host so that a valid older snapshot can be recognized as a rollback.

Terminal
tempus checkpoint create --tenant-id acme --out checkpoint-acme.json
tempus checkpoint export --tenant-id acme --from-seq 1 --out stream-acme.json
tempus checkpoint verify --checkpoint checkpoint-acme.json --stream stream-acme.json

Follow the backup and disaster recovery procedures for retention and reconciliation.

Reference / Security

Know the current limits.

  • Agent access to downstream credentials makes the executor boundary bypassable.
  • Multi-instance executors need shared transactional consumption state; the current local guarantees do not establish distributed replay safety.
  • Raw evidence is not automatically confidential. Plan how you handle sensitive payloads.
  • The payment adapter requires your own real provider integration; Tempus does not supply custody or transaction reversal.

Full threat model ↗ · Roadmap ↗ · Security reporting ↗