LedgerCovenant — Verifiable credit covenant decisions
Product identity
LedgerCovenant is a bitemporal covenant compliance engine for credit facilities. Insight IT Solutions LLC (Insight ITS) makes it. Category: Research — verifiable covenant decision engine for credit facilities. Problem: A leverage covenant is arithmetic over a definition that three amendments have rewritten, using a figure two sources report differently. It is for Credit agreement admins, portfolio monitoring leads, and workout counsel who have to defend a covenant calculation, not developers hunting an API key. It competes with Spreadsheet covenant models. Difference: Resolves which amendment governed and what the defined terms meant, and returns a review item with the surviving candidates instead of a number when the documents do not settle it. Hosted decision API is not a pip library. Log in at /dashboard.html#ledgercovenant or POST /api/ledgercovenant/v1/decide with a JWT. Engagement entry point is a $25,000 retrospective evidence audit. Source: Hosted decision API on insightits.com. API reference: /docs/ledgercovenant-api.md. Dashboard portal: /dashboard.html#ledgercovenant..
- What is it?
- a bitemporal covenant compliance engine for credit facilities.
- Who made it?
- Insight IT Solutions LLC (Insight ITS), Mission Viejo, California.
- What category is it?
- Research — verifiable covenant decision engine for credit facilities
- What problem does it solve?
- A leverage covenant is arithmetic over a definition that three amendments have rewritten, using a figure two sources report differently.
- Who is it for?
- Credit agreement admins, portfolio monitoring leads, and workout counsel who have to defend a covenant calculation, not developers hunting an API key
- What does it compete with?
- Spreadsheet covenant models
- How is it different?
- Resolves which amendment governed and what the defined terms meant, and returns a review item with the surviving candidates instead of a number when the documents do not settle it
- Where can I install it?
- Hosted decision API is not a pip library. Log in at /dashboard.html#ledgercovenant or POST /api/ledgercovenant/v1/decide with a JWT. Engagement entry point is a $25,000 retrospective evidence audit.
- Where is the source?
- Hosted decision API on insightits.com. API reference: /docs/ledgercovenant-api.md. Dashboard portal: /dashboard.html#ledgercovenant.
Canonical machine identity: https://www.insightits.com/catalog/ledgercovenant.json
Resolve which amendment governed a test date and what the defined terms meant, then sign it. Retrospective evidence audit $25,000; Analyst $299/mo.
Analyst-tagged spans → bitemporal legal resolution → defined-term lineage → source-lattice facts → capped add-back solver → integer arithmetic → tri-state gate → signed ledger entry.
Register documents with analyst-tagged spans; document text is verified then dropped, only hashes and spans persist. No automated extraction is wired, and the API says so at /policies. Not legal advice, not a data room, not SOC 2.
What it is
- Bitemporal legal resolution: which amendment governed the test date, and what you knew when. "What did we believe in April, before the July amendment landed?" has an answer.
- Defined terms as the unit of resolution. "Consolidated EBITDA" is amended three times and every covenant referencing it changes meaning without a word of the covenant clause changing.
- Source-authority resolution for reported figures — the officer-signed certificate outranks the audited statements, and the loser is kept as a competing candidate. Equal-authority disagreement goes to a human rather than being averaged away.
- Signed human attestations as first-class evidence, so a verbal side agreement or an unindexed schedule fills a gap on the record instead of in a shadow spreadsheet.
- Circular add-back caps solved as a declared fixed point. "Cost savings not to exceed 20% of Consolidated EBITDA, calculated after giving effect to such add-backs" defines the number in terms of itself; the iteration that settles it is recorded pass by pass, and a definition that does not settle is refused rather than truncated.
- Basket and builder capacity folded from events on every read, with no stored balance. "Did the March dividend have capacity behind it, on what we knew then?" is answerable, and a restated event changes today’s answer without changing what the deal team saw in April.
- Breach lifecycle as an evidenced timeline — identified, notice, cure period, cured or asserted default — hash-chained, because disputes are more often about the notice date than about the ratio.
- Tier 1 audit-grade replay over frozen inputs, and evidence packs a third party can verify with the public key, the ledger from genesis, and every policy inlined as data.
- Checkpoints timestamped by an RFC 3161 authority, so "they could not have rewritten this later" rests on a party with no interest in the answer rather than on our own signature. Only the head hash leaves the building — never a borrower, a facility, or a figure.
What it is not
- Not automated document extraction, in the sense that word usually carries. A deterministic pattern matcher proposes candidate spans and writes nothing; an analyst still decides what becomes evidence, and candidate confidence is the precision measured against that analyst’s own tags or zero. It cannot tell whether the sentence it matched is the operative one — a definition quoted in a recital looks identical to the governing one.
- Not a data room, a document store, or a portfolio monitoring system. Document text is never stored — only content hashes and the tagged spans.
- Not legal advice. The pack proves what was decided on what evidence under which rules; whether the reading of the contract is correct is a judgement a hash cannot establish.
- Not a declaration of default. The system reports that a cure window elapsed, which is arithmetic about a date, and stops there. Recording that a default was asserted requires a signed attestation naming who asserted it.
- Not a covenant calculator you point at a PDF. Setting up a facility is deliberate work, which is why the entry engagement is a scoped retrospective audit.
Integration
Register
POST the credit agreement and each amendment with the spans your analyst tagged. Offsets are verified against the text; only hashes and spans are kept.
Define
Record defined terms, their amendment lineage, the obligations that reference them, and the threshold step-down schedule.
Decide
POST /decide for an obligation and a test period. ACCEPT signs a decision onto the ledger; REVIEW and REFUSE open review items naming the specific artifact.
Prove
Replay Tier 1 to reproduce the decision from frozen inputs, or export an evidence pack for counsel, an auditor, or a disputing lender.
Pricing
Retrospective Evidence Audit — $25,000 one-time
10 historical facilities with known outcomes — ideally ones that already had a dispute. Includes Desk-tier access. Larger scopes quoted.
Sandbox — Free
1 facility · 25 decisions / month · signed with a marked development key, so it cannot produce a regulatory artifact
Analyst — $299 / mo
3 facilities · 500 decisions / month · Tier 1 replay · evidence pack export · 1 attestor seat
Desk / Team — $1,499 / mo
15 facilities · 5,000 decisions / month · deal-team walls · Tier 2 diagnostic replay · checkpoint anchoring · WORM evidence retention · 5 attestor seats
Enterprise — From $6,000 / mo
Unlimited facilities and decisions · custom precedence policy · invoiced (contact sales)
FAQ
What does LedgerCovenant actually decide?
For one obligation and one test period: which provision governed on that date, which reported figure governs when sources disagree, what the ratio is, and whether that breaches the threshold in force. Each stage produces a trace, and the whole thing is signed onto a hash-chained ledger.
Does it read my credit agreement automatically?
Not in the sense that question usually means. A deterministic pattern matcher will propose candidate spans — defined-term openings, ratios like 3.50:1.00, percentage caps, cure-day windows, step-downs — and it writes nothing; an analyst still submits what becomes evidence, and the offsets are verified against the text and rejected if the quoted words do not match, which catches offsets pasted from a version that reflowed after an amendment. What a regular expression cannot do is tell whether the sentence it matched is the operative one: a definition quoted in a recital, an example in a schedule, and the governing definition in Section 1.01 are indistinguishable to it. There is no OCR and no language model in the path.
How accurate is the automated extraction?
As accurate as it has been measured on your own documents, and zero until it has been. Running an evaluation scores the extractor against the spans your analyst already tagged and stores precision and recall per label — both, because a pattern that fires on every sentence has perfect recall and one that fires once has excellent precision, so either number alone is a sales figure. Every measurement is marked in-sample: those documents were already tagged, so the result describes agreement on documents already seen and predicts nothing about the next agreement. An unmeasured label reports 0.0 confidence, which fails the decision gate rather than passing quietly.
Do you store my credit agreements?
No. Document text is used to verify span offsets and compute a content hash, then dropped. Only the content hash, the tagged spans, and their hashes are kept. Anyone holding the original can prove it matches what a decision relied on. The cost is stated plainly: Tier 2 diagnostic replay needs you to resubmit the document.
What happens when two clauses conflict?
The precedence ladder runs — amendment lineage, then temporal narrowness, then document authority, then specificity — and if more than one provision survives, the result is AMBIGUOUS with all surviving candidates, routed to a review queue. It does not fall back to picking the most recent. Under the default policy, winning on recording order alone is not permitted.
What happens when two sources report different numbers?
Source authority decides, using a versioned lattice: the officer-signed compliance certificate outranks audited financials, which outrank reviewed, management accounts, system exports, and correspondence. The loser is recorded as a competing candidate rather than discarded. If two sources of equal rank disagree — a corrected compliance certificate against the original, say — that is a conflict for an analyst, not an average and not "take the newer one". Tolerance is exact unless you opt in per fact key, and when tolerance is used the trace says so.
Can a human override the system?
A human can attest, which is different. An attestation is a signed, expiring, attributable evidence artifact that fills a gap — a verbal side agreement, an unindexed schedule, a judgement call on an ambiguity. It enters the source lattice at the floor, below every document source, and decisions resting on attestations are flagged as such in the evidence pack.
How do you handle an add-back cap that depends on the number it is capping?
"Cost savings not to exceed 20% of Consolidated EBITDA, calculated after giving effect to such add-backs" defines the amount in terms of itself, and once several such caps interact there is no closed form. The amount is treated as a fixed point and found by iterating upward from the uncapped base until two successive passes agree on the exact integer. Iterating upward reaches the least fixed point, which is the borrower-conservative reading. The trace records every pass, so an auditor can see the iteration rather than being handed a number. If the caps hand back so much of the result that the passes creep instead of settling, the declared budget runs out and the answer is DERIVATION_NO_CONVERGENCE — reporting the last iterate would be inventing a limit the document does not contain.
What if an add-back is capped but nobody tagged the cap?
It is refused with DERIVATION_CAP_UNDEFINED. It is never defaulted to uncapped. Silently admitting an add-back in full because its limit was not recorded is exactly the error the product exists to catch, so the one thing it must not do is commit that error itself.
How is builder-basket capacity tracked?
As a fold over dated events — grants, usages, restorations, expiries, resets — recomputed on every read. There is no balance column anywhere, because a cached balance becomes a second source of truth that disagrees with the events the first time one is restated, and the cache is what the report reads. Capacity is answered as of a date and as of a knowledge time, which are different questions: a reclassified investment changes today’s answer without changing what the deal team saw in April. A usage is tested against the basket as it stood on the day of the payment, not today.
What happens if a borrower paid a dividend with no basket capacity?
That is recorded, flagged as an overdraw, and reported — because it happened. The check refuses by default with BASKET_INSUFFICIENT and shows the available amount and the shortfall; recording it anyway takes an explicit allowOverdraw flag. A system that refuses to represent a payment the borrower actually made just pushes the truth into a spreadsheet, which is the failure mode we are replacing.
Does it declare an event of default?
No, and that boundary is deliberate. The breach lifecycle records identification, notice, cure period, and resolution as an evidenced, hash-chained timeline, and it reports that a cure window elapsed — which is arithmetic about a date. It stops there. Nothing auto-advances to default. Serving notice, accepting a cure, granting a waiver, and asserting a default are acts by a person, and each requires a signed, verified attestation naming who took it. We say what the evidence shows; a person says what it means.
What does "deterministic replay" mean here, precisely?
Tier 1 rehydrates the exact assertion hashes a decision froze and re-runs only resolution, fact weighting, and integer arithmetic under the policy versions pinned at decision time. It never calls an extractor. If the frozen inputs no longer hash the same, replay stops and says so rather than reporting a mismatch — the distinction between "the inputs moved" and "the engine regressed" is the whole diagnostic value. Tier 2 re-reads source documents and is explicitly non-binding.
Can an auditor verify a decision without trusting you?
That is the design constraint. An evidence pack carries the Ed25519 public key, the ledger from genesis, every policy version inlined as data rather than by reference, RFC 8785 canonicalization conformance vectors so a verifier can check its own JSON serializer first, and step-by-step integer arithmetic. It also carries a section stating what it does not prove.
You sign the ledger, so what stops you from rewriting it?
On its own, nothing — a checkpoint we sign proves the chain is internally consistent, and we hold the key. So checkpoints are timestamped by an RFC 3161 authority: the head hash is submitted as a bare digest, and the token that comes back is only recorded if the imprint matches what we sent, the nonce matches the one we generated, the CMS signature verifies against the embedded certificate, and that certificate carries the timestamping key usage. Fail any of those and the request is refused rather than recorded, because a checkpoint claiming an anchor it cannot prove is worse than one claiming none. The token is stored verbatim so you can verify it against your own trust store with openssl and take our word for nothing.
What stops the evidence from being deleted rather than altered?
Different question, and the ledger does not answer it. Evidence packs can be written to S3 with Object Lock in COMPLIANCE mode, which no principal in the account can bypass, for seven years by default rather than the customary one — a dispute over a 2026 test date can plausibly be litigated in 2032, and retention that expires before the claim does is retention theatre. The lock is read back after the write, and if it cannot be confirmed the response says so instead of asserting durability.
Can a script or CI job drive this, and can it attest?
Yes to the first, deliberately never to the second. Machine keys carry explicit scopes — read, decide, replay, evidence, anchor — and can be pinned to specific facilities, which narrows what they reach and never widens it. There is no attest scope and there will not be one: an attestation is a named person taking responsibility for a statement about a credit agreement, and it is what lets a decision proceed over a gap in the documents, so a credential on a build runner able to sign one would make the strongest evidence in the system the cheapest to produce. Attesting, superseding a decision, moving an information wall, and issuing keys all require a signed-in person. Asking for the forbidden scopes is refused when the key is created, not when it is used.
How are corrections handled after a decision is signed?
By supersession, never by editing. A restated financial produces a new decision, a supersession record linking the two with a reason code and a narrative, and a mandatory attestation. Both decisions stay readable and both appear in the evidence pack. That is how audit actually works.
Is arithmetic done in floating point?
No, and the system refuses to hash a float in an evidence payload at all. Amounts and ratios are scaled integers with an explicit scale; division happens in a pinned Decimal context with an explicit rounding mode that travels in the trace.
How is LedgerCovenant priced?
The entry point is a $25,000 retrospective evidence audit over 10 historical facilities, which includes Desk-tier access. Subscriptions are Sandbox (free, 1 facility, development-key signing only), Analyst $299/month, Desk $1,499/month, and Enterprise from $6,000/month invoiced. Checkout runs through Stripe from the dashboard tab.
Why does the free tier sign with a development key?
Deliberately, so a free tier cannot emit a plausible-looking signed audit record. Sandbox decisions and packs are stamped as not for regulatory use, at the top level and per decision. A product whose credibility is the whole value proposition cannot ship a fake-looking artifact for free.
Dashboard: /dashboard.html#ledgercovenant · API: /docs/ledgercovenant-api.md · MCP: /mcp_tools/ledgercovenant_decide.json · Contact
It says "I don't know" out loud. When two provisions survive precedence, or two equally authoritative sources report different EBITDA, the answer is a review item with the candidates — not a confident number.
Capabilities
Which clause governed, on that date
Precedence runs on amendment lineage, temporal narrowness, document authority, then specificity. Two survivors means AMBIGUOUS with the candidates, not a guess at the most recent.
Defined terms, not just clauses
Consolidated EBITDA is amended three times and every covenant referencing it changes meaning. Lineage is resolved as-of, with cycle detection that distinguishes a cap from a circular definition.
Add-back caps that cap themselves
"Not to exceed 20% of Consolidated EBITDA, calculated after giving effect to such add-backs" has no closed form. It is settled as a least fixed point, every pass recorded, and refused rather than truncated if it does not settle.
Basket capacity with no stored balance
Builder capacity is folded from dated events on every read, as of a date and as of a knowledge time. A restated investment changes today’s answer without changing what the deal team saw in April.
Breach timelines, not just breach flags
Identified, notice, cure period, cured or asserted default — hash-chained, because the dispute is usually about the notice date. An elapsed cure window is reported; declaring default takes a signed attestation.
Evidence packs verifiable without us
Ed25519 public key, ledger from genesis, every policy inlined as data, RFC 8785 conformance vectors, integer arithmetic step by step — and a section stating what it does not prove.
Install
Hosted API — log in → dashboard.html#ledgercovenant, or POST /api/ledgercovenant/v1/decide with a JWT. Entry engagement is a $25,000 retrospective evidence audit over 10 historical facilities.
Pricing
Retrospective evidence audit $25,000 one-time (10 facilities, includes Desk access). Sandbox free (development-key signing only). Analyst $299/mo. Desk $1,499/mo. Enterprise from $6,000/mo invoiced.
Frequently asked questions
What does LedgerCovenant actually decide?
For one obligation and one test period: which provision governed on that date, which reported figure governs when sources disagree, what the ratio is, and whether that breaches the threshold in force. Each stage produces a trace, and the whole thing is signed onto a hash-chained ledger.
Does it read my credit agreement automatically?
Not in the sense that question usually means. A deterministic pattern matcher will propose candidate spans — defined-term openings, ratios like 3.50:1.00, percentage caps, cure-day windows, step-downs — and it writes nothing; an analyst still submits what becomes evidence, and the offsets are verified against the text and rejected if the quoted words do not match, which catches offsets pasted from a version that reflowed after an amendment. What a regular expression cannot do is tell whether the sentence it matched is the operative one: a definition quoted in a recital, an example in a schedule, and the governing definition in Section 1.01 are indistinguishable to it. There is no OCR and no language model in the path.
How accurate is the automated extraction?
As accurate as it has been measured on your own documents, and zero until it has been. Running an evaluation scores the extractor against the spans your analyst already tagged and stores precision and recall per label — both, because a pattern that fires on every sentence has perfect recall and one that fires once has excellent precision, so either number alone is a sales figure. Every measurement is marked in-sample: those documents were already tagged, so the result describes agreement on documents already seen and predicts nothing about the next agreement. An unmeasured label reports 0.0 confidence, which fails the decision gate rather than passing quietly.
Do you store my credit agreements?
No. Document text is used to verify span offsets and compute a content hash, then dropped. Only the content hash, the tagged spans, and their hashes are kept. Anyone holding the original can prove it matches what a decision relied on. The cost is stated plainly: Tier 2 diagnostic replay needs you to resubmit the document.
What happens when two clauses conflict?
The precedence ladder runs — amendment lineage, then temporal narrowness, then document authority, then specificity — and if more than one provision survives, the result is AMBIGUOUS with all surviving candidates, routed to a review queue. It does not fall back to picking the most recent. Under the default policy, winning on recording order alone is not permitted.
What happens when two sources report different numbers?
Source authority decides, using a versioned lattice: the officer-signed compliance certificate outranks audited financials, which outrank reviewed, management accounts, system exports, and correspondence. The loser is recorded as a competing candidate rather than discarded. If two sources of equal rank disagree — a corrected compliance certificate against the original, say — that is a conflict for an analyst, not an average and not "take the newer one". Tolerance is exact unless you opt in per fact key, and when tolerance is used the trace says so.
Can a human override the system?
A human can attest, which is different. An attestation is a signed, expiring, attributable evidence artifact that fills a gap — a verbal side agreement, an unindexed schedule, a judgement call on an ambiguity. It enters the source lattice at the floor, below every document source, and decisions resting on attestations are flagged as such in the evidence pack.
How do you handle an add-back cap that depends on the number it is capping?
"Cost savings not to exceed 20% of Consolidated EBITDA, calculated after giving effect to such add-backs" defines the amount in terms of itself, and once several such caps interact there is no closed form. The amount is treated as a fixed point and found by iterating upward from the uncapped base until two successive passes agree on the exact integer. Iterating upward reaches the least fixed point, which is the borrower-conservative reading. The trace records every pass, so an auditor can see the iteration rather than being handed a number. If the caps hand back so much of the result that the passes creep instead of settling, the declared budget runs out and the answer is DERIVATION_NO_CONVERGENCE — reporting the last iterate would be inventing a limit the document does not contain.
What if an add-back is capped but nobody tagged the cap?
It is refused with DERIVATION_CAP_UNDEFINED. It is never defaulted to uncapped. Silently admitting an add-back in full because its limit was not recorded is exactly the error the product exists to catch, so the one thing it must not do is commit that error itself.
How is builder-basket capacity tracked?
As a fold over dated events — grants, usages, restorations, expiries, resets — recomputed on every read. There is no balance column anywhere, because a cached balance becomes a second source of truth that disagrees with the events the first time one is restated, and the cache is what the report reads. Capacity is answered as of a date and as of a knowledge time, which are different questions: a reclassified investment changes today’s answer without changing what the deal team saw in April. A usage is tested against the basket as it stood on the day of the payment, not today.
What happens if a borrower paid a dividend with no basket capacity?
That is recorded, flagged as an overdraw, and reported — because it happened. The check refuses by default with BASKET_INSUFFICIENT and shows the available amount and the shortfall; recording it anyway takes an explicit allowOverdraw flag. A system that refuses to represent a payment the borrower actually made just pushes the truth into a spreadsheet, which is the failure mode we are replacing.
Does it declare an event of default?
No, and that boundary is deliberate. The breach lifecycle records identification, notice, cure period, and resolution as an evidenced, hash-chained timeline, and it reports that a cure window elapsed — which is arithmetic about a date. It stops there. Nothing auto-advances to default. Serving notice, accepting a cure, granting a waiver, and asserting a default are acts by a person, and each requires a signed, verified attestation naming who took it. We say what the evidence shows; a person says what it means.
What does "deterministic replay" mean here, precisely?
Tier 1 rehydrates the exact assertion hashes a decision froze and re-runs only resolution, fact weighting, and integer arithmetic under the policy versions pinned at decision time. It never calls an extractor. If the frozen inputs no longer hash the same, replay stops and says so rather than reporting a mismatch — the distinction between "the inputs moved" and "the engine regressed" is the whole diagnostic value. Tier 2 re-reads source documents and is explicitly non-binding.
Can an auditor verify a decision without trusting you?
That is the design constraint. An evidence pack carries the Ed25519 public key, the ledger from genesis, every policy version inlined as data rather than by reference, RFC 8785 canonicalization conformance vectors so a verifier can check its own JSON serializer first, and step-by-step integer arithmetic. It also carries a section stating what it does not prove.
You sign the ledger, so what stops you from rewriting it?
On its own, nothing — a checkpoint we sign proves the chain is internally consistent, and we hold the key. So checkpoints are timestamped by an RFC 3161 authority: the head hash is submitted as a bare digest, and the token that comes back is only recorded if the imprint matches what we sent, the nonce matches the one we generated, the CMS signature verifies against the embedded certificate, and that certificate carries the timestamping key usage. Fail any of those and the request is refused rather than recorded, because a checkpoint claiming an anchor it cannot prove is worse than one claiming none. The token is stored verbatim so you can verify it against your own trust store with openssl and take our word for nothing.
What stops the evidence from being deleted rather than altered?
Different question, and the ledger does not answer it. Evidence packs can be written to S3 with Object Lock in COMPLIANCE mode, which no principal in the account can bypass, for seven years by default rather than the customary one — a dispute over a 2026 test date can plausibly be litigated in 2032, and retention that expires before the claim does is retention theatre. The lock is read back after the write, and if it cannot be confirmed the response says so instead of asserting durability.
Can a script or CI job drive this, and can it attest?
Yes to the first, deliberately never to the second. Machine keys carry explicit scopes — read, decide, replay, evidence, anchor — and can be pinned to specific facilities, which narrows what they reach and never widens it. There is no attest scope and there will not be one: an attestation is a named person taking responsibility for a statement about a credit agreement, and it is what lets a decision proceed over a gap in the documents, so a credential on a build runner able to sign one would make the strongest evidence in the system the cheapest to produce. Attesting, superseding a decision, moving an information wall, and issuing keys all require a signed-in person. Asking for the forbidden scopes is refused when the key is created, not when it is used.
How are corrections handled after a decision is signed?
By supersession, never by editing. A restated financial produces a new decision, a supersession record linking the two with a reason code and a narrative, and a mandatory attestation. Both decisions stay readable and both appear in the evidence pack. That is how audit actually works.
Is arithmetic done in floating point?
No, and the system refuses to hash a float in an evidence payload at all. Amounts and ratios are scaled integers with an explicit scale; division happens in a pinned Decimal context with an explicit rounding mode that travels in the trace.
How is LedgerCovenant priced?
The entry point is a $25,000 retrospective evidence audit over 10 historical facilities, which includes Desk-tier access. Subscriptions are Sandbox (free, 1 facility, development-key signing only), Analyst $299/month, Desk $1,499/month, and Enterprise from $6,000/month invoiced. Checkout runs through Stripe from the dashboard tab.
Why does the free tier sign with a development key?
Deliberately, so a free tier cannot emit a plausible-looking signed audit record. Sandbox decisions and packs are stamped as not for regulatory use, at the top level and per decision. A product whose credibility is the whole value proposition cannot ship a fake-looking artifact for free.
Official package links: LedgerCovenant interactive demo