Covenant Change Detection

Compare baseline agreements with amendments and build current terms through human review.

Covenant Change Detection organises agreements, proposed changes, evidence, and review decisions. Its central distinction is between a model-generated proposal and a change a person has reviewed. Pending proposals do not silently become current terms.

Prepare the document set

1. Create the app and upload your baseline agreement, amendments, and supporting documents.
2. Capture each source for review so the analysis refers to preserved bytes rather than an original that might later change.
3. Assign each document its role: baseline, amendment, or other. Identify one baseline for the review set.
4. Inspect the document list, captured identifiers, and any detected borrower, type, or signature information.

Use complete and legible source documents. The app does not arrive with your agreements already loaded. A capture failure should be resolved before relying on that source for a proposal.

Generate proposals

Choose Generate proposals after the document set and roles are correct. The app’s analysis workflow produces proposed comparisons with covenant, previous requirement, proposed requirement, explanation of the change, effective date, effectiveness review, and review status.

If generation is interrupted or its outcome is uncertain, check the saved generation before asking for another. A repeated click should not be the first way to find out whether the earlier request completed. Inspect the generation result, source set, and workflow run together.

Review a proposed change

Open the relevant baseline and amendment evidence. Check the stated requirement, thresholds, conditions, waivers, definition changes, and asserted effective date. A signed document and an effective amendment are different facts; consider the effectiveness conditions present in the source.

Record the human review outcome. Only an authorised person’s decision moves a proposal through review. Editing the payload or its source basis can require review again because an earlier decision applied to a different version. Generation itself never approves a proposal.

Approval and effectiveness confirmation are separate. Review the Baseline effectiveness confirmed, Baseline effective date, Amendment effectiveness confirmed, and Amendment effective date fields against the captured evidence. Only changes that are both approved and effectiveness-confirmed enter current covenants.

Read current terms and history

The current-terms view summarises reviewed requirements, thresholds, conditions, active waivers, and definition changes that still need attention. History shows the covenant, action, effective date, review outcome, and previous and current requirement. The issues view highlights proposals and reasons needing review.

Choose the as-of date and refresh the reviewed state to inspect terms for that date. After changing a decision, effectiveness field, or date, refresh rather than assuming the existing projection has already updated. The selected date determines which eligible reviewed changes contribute to the displayed state.

Use history and source evidence to understand why a term appears current. The app helps organise comparison and review; it does not automatically decide compliance, declare default, or resolve every ambiguity in an agreement. Keep unresolved effectiveness and interpretation questions visible.

Operate the app

The app uses managed document review and its analysis workflow. Your administrator must make the required capabilities available. Sharing the app interface does not automatically share the owner’s private review ledger. Review captured evidence and decisions before adapting access or retention. Preserve the evidence and reviewed results you need separately from an app-definition export.

Parameter reference

These are the starting template’s declared parameters. Your saved app can have its own version of the schema. A default applies when no explicit value is supplied; a required field still needs a valid value.

• title: exposed as an app interface parameter.

Connection slots

Choose compatible saved connections for user-supplied slots. Managed slots are supplied by Strive. Disabling an optional slot stops its use without necessarily deleting the saved binding. See connector policy.

Included workflows

Inspect the saved app’s workflows for changes made after creation. A workflow’s presence does not mean that every interaction runs every workflow.