The repository or configuration that created this release differ from a previous release. View details.
commitlayer (Python)
Record agent actions, push facts from systems of record, read verdicts and draft contracts. Standard library only; Python 3.10+.
pip install commitlayer
export COMMITLAYER_API_KEY=spk_... # the agent runtime's key: a *recorder* key (records actions, nothing else)
export COMMITLAYER_EVIDENCE_KEY=spk_... # the pipeline's key: an *evidence* key bound to the sources it pushes for
# COMMITLAYER_API_URL defaults to https://api.commitlayer.ai. One credential per side of the line: the key that
# records an action can never also supply the facts that verify it.
Record an action where it happens
from commitlayer import Client
cl = Client(agent_id="support-bot")
@cl.action(
"refund_workflow",
subject=lambda order_id, **_: order_id,
params=lambda amount, **_: {"amount": amount},
subject_kind="order",
action_id=lambda order_id, **_: f"refund:{order_id}", # retries update one claim instead of recording two
)
def refund(order_id: str, amount: float) -> dict:
return payments.refund(order_id, amount) # the agent's own work, unchanged
refund("order_10231", 180.0)
print(refund.last_recorded["verification"]["summary"]["headline"])
The action is recorded before the function runs, so its request time precedes every effect. The function's
return value is never changed and never consulted: verification reads the systems of record. If the API cannot
be reached the function still runs and a warning is logged (fail_open=True); pass fail_open=False to raise.
Push facts, with a watermark
Use an evidence key here, bound to the sources it pushes for (Settings → API keys). The key your agent runtime records actions with is a recorder key and cannot push facts: the credential that records an action never also supplies the facts that verify it.
import os
evidence = Client(api_key=os.environ["COMMITLAYER_EVIDENCE_KEY"]) # the pipeline's own client, not the runtime's
evidence.push_facts(
[
{
"source": "crm",
"subject_id": "order_10231",
"fact_type": "note_added",
"occurred_at": "2026-10-13T10:42:09Z",
}
],
watermarks={"crm": "2026-10-13T10:45:00Z"}, # everything up to here has been sent for crm
)
A verdict that is not yet a PASS settles only when its window has closed and every source it reads has a watermark past the end of the window. Declare one when your feed lags; a source that never declares one is taken as current.
Draft a contract from what was recorded
d = cl.draft_contract("refund_order", lookback_days=30)
print(d["yaml"]) # expected effects, window, preconditions, limits, from the sample
print(d["stats"]["effects"])
v = cl.validate_contract(d["yaml"]) # errors, and weakening warnings against the version it would replace
cl.save_contract(d["yaml"]) # the response carries the same warnings
Every value in a draft is what the sample showed, not what the policy says. Review it before saving.
Read a verdict
v = cl.get_action("refund:order_10231")
v["status"] # pending | settled
v["settlement"]["waiting_on"] # sources still behind the window, if any
v["reversal"] # the later record that undid the action, if any
v["sources"] # trust level and watermark per source the contract read
Wait for the verdict before saying "done"
v = cl.wait_for_settlement("refund:order_10231", timeout=300) # blocks until settled or 5 minutes
if v["timed_out"]:
... # still pending: your policy, never "success"
elif v["lenses"]["outcome"]["verdict"] == "PASS":
notify_customer("Your order is cancelled and refunded.")
else:
open_recovery(v) # FAIL: the reasons name what is missing or forbidden
The API holds each call for up to 60 seconds; the SDK loops. The gate reads evidence; it never changes a verdict.
Correct a failed action
cl.record_action(
"refund_workflow",
"order_10231",
params={"amount": 180.0},
action_id="refund:order_10231:fix",
compensates="refund:order_10231",
)
Once the correction settles PASS, the failed action carries resolution.state == "compensated"; its own verdict never changes.
Metadata
Release files for commitlayer 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Change of provenance
The repository or configuration that created these release files differ from that of a previous release.
We recommend inspecting the repository and configuration before proceeding. View details.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| commitlayer-0.1.1.tar.gz | 7.8 kB | With provenance | Details for commitlayer-0.1.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| commitlayer-0.1.1-py3-none-any.whl | Python 3 | none | any | Details for commitlayer-0.1.1-py3-none-any.whl |
Total release size: 16.0 kB
Release files / commitlayer-0.1.1.tar.gz
Change of provenance
This file belongs to a release with changed provenance: the repository or configuration that created the release files differ from that of a previous release.
We recommend inspecting the repository and configuration before proceeding. View details.
| Download URL | commitlayer-0.1.1.tar.gz |
|---|---|
| Size | 7.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
7f603883fa696dd72f452974bee4b5e2e7d1cc0578836f6e3aa4933d431f6a3f
|
|
BLAKE2b-256 checksum How to use checksums |
8a337683457b59b41d09af549a815dfc9ee020767fc678ea3d8f11f75060e99b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 10, 2026.
Transparency logRelease files / commitlayer-0.1.1-py3-none-any.whl
Change of provenance
This file belongs to a release with changed provenance: the repository or configuration that created the release files differ from that of a previous release.
We recommend inspecting the repository and configuration before proceeding. View details.
| Download URL | commitlayer-0.1.1-py3-none-any.whl |
|---|---|
| Size | 8.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
be69370ad7039f1a5981fddff807a80c246722c4797bc1cd96f3128d78023317
|
|
BLAKE2b-256 checksum How to use checksums |
5fde903cb6064c1e71ca781df1e489b0402e63b6f2d5fd5ab10ced955af724b1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 10, 2026.
Transparency logSecurity for commitlayer 0.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Change of provenance
The repository and configuration that created this release differ from a previous release.
While this could reflect a routine change by the project maintainers, it may also indicate that the release files have been compromised.
Repository
- Removed 0.1.0 github.com/kobikwelu/stateprf-svcs
- Added 0.1.1 github.com/commitlayer/commitlayer
Attestation for commitlayer-0.1.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 10, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.