This Master Services Agreement is between J&J Pulliam Enterprises LLC, a Texas limited liability company doing business as InboxAssure ("Company," "we," "us"), and the business named on the Order Form ("Client," "you"). This Agreement and each Order Form together form the contract (the "Agreement").
1. Acceptance, Payment Authorization, and Roles
1.1 How Client accepts. Client accepts this Agreement only through an affirmative act by the Purchaser (defined below): checking an unchecked acceptance box next to the displayed terms and price, or signing an Order Form. Connecting an API key, logging in, or using the Services is not acceptance of this Agreement or of any billing.
1.2 Purchaser. The "Purchaser" is the individual who accepts on Client's behalf. The Purchaser represents that they are authorized to bind Client to this Agreement and its fees.
1.3 Payment authorization is separate. Recurring charges require a separate payment authorization given by the Purchaser or another person Client designates as authorized to use the payment method (the "Payer"). Company records the Payer's name, email, the amount and billing frequency shown, and the time of authorization.
1.4 Connector Operators. Client may designate one or more people to connect tools and choose settings (each a "Connector Operator"). A Connector Operator's authority is limited to the permissions recorded under Section 3. A Connector Operator does not accept this Agreement, authorize charges, or change the plan unless Company separately records that they are also a Purchaser or Payer.
1.5 Business use. The Services are sold to businesses for commercial purposes.
1.6 Electronic records. The parties agree to electronic signatures and records under the federal ESIGN Act and the Texas Uniform Electronic Transactions Act. Company keeps a record of each acceptance, authorization, and permission choice, including the person, time, IP address, and the exact rendered text and version shown.
2. Description of Services
2.1 Service lines. Client's Order Form states which of these Company provides:
- (a) InboxAssure Platform: scheduled inbox placement testing on sampled sending domains and, where permitted under Section 3, automated adjustment of sending limits based on those scheduled results.
- (b) InboxAssure Diagnostic: a read only diagnostic that connects to Client's email sequencer and the InboxAssure placement feed, preserves the available sending and response history, runs registered checks against it, and reports findings, alerts, reviews, and dated reports. Schedule A describes it.
- (c) Fractional Deliverability Expert: scheduled strategy calls and written recommendations.
2.2 Plan contents. For each service line purchased, the Order Form lists:
- (a) Supported Integrations: only providers Company supports for that service line today, as shown in the table below.
- (b) Included Features: each with its current status from Schedule A.
- (c) Client Controls: the settings Client may change, listed in Schedule B.
- (d) Company Managed Settings: the settings Company configures, listed in Schedule B.
- (e) quantities, schedules, and fees.
| Sequencer | InboxAssure Platform | InboxAssure Diagnostic |
|---|---|---|
| EmailBison | Supported | Supported |
| Instantly | Planned | Planned |
| SmartLeads | Planned | Planned |
A Planned integration is not part of the Services, is not billed for, and is not shown as supported at checkout until Company notifies Client in writing that it is live. The InboxAssure Diagnostic requires two read only sources: Client's email sequencer, from the supported list in the table above, and the InboxAssure placement feed. The Diagnostic cannot be used without both.
Integrations, features, and controls not listed on the Order Form are not part of the Services.
2.3 Feature status. Schedule A labels each feature as Implemented, Published (first test), Built but Operationally Blocked, or Not Offered. Company does not charge for, and the Order Form does not include, any feature labeled Built but Operationally Blocked until Company notifies Client in writing that it is available. Features labeled Not Offered are not part of the Services.
2.4 How automation works. Only the InboxAssure Platform takes automated actions on sending. Where Client has granted Change Sending Limits, it lowers, pauses, or restores sending accounts based on scheduled automated tests and on bounce protection rules. Where Client has granted Pause Campaigns, it pauses and resumes campaigns under bounce rate and account disconnection rules. Results of manually run or single diagnostic tests are informational and do not by themselves change sending. The InboxAssure Diagnostic never changes sending or campaigns, and adds entries to Client's sequencer blacklist only when Client approves a previewed list.
2.5 What the Services are not. Company does not guarantee inbox placement, open or reply rates, meetings, pipeline, revenue, or any business result, and does not attribute revenue to the Services. Company does not control mailbox providers, spam filters, email gateways, blacklists, or third party platforms. Company does not deploy or send Client's prospecting campaigns, and does not verify prospect addresses over SMTP. Rewritten copy produced by the InboxAssure Diagnostic for testing is a suggestion; Client decides whether to use it.
2.6 What findings mean. A diagnostic finding describes an association or condition in Client's retained history for the period studied. It is not proof of cause, a forecast, or a universal rule. A check may report that it cannot reach a conclusion. Placement results describe tested seed cohorts, not every recipient. Warmup scores describe the warmup network, not prospect placement.
2.7 Results depend on many factors. Deliverability depends on list quality, copy, domain age, volume, warmup, provider behavior, and recipient behavior, many of which are outside Company's control.
3. Permissions
3.1 Five separate permissions. Company may take each of these actions in Client's connected tools only if Client has granted that specific permission:
| Permission | What it allows | Service lines that use it |
|---|---|---|
| Read Data | Read account, campaign, mailbox, reply, and test data needed to provide the Services | All |
| Change Sending Limits | Lower, pause, or restore sending limits on Client's sending accounts, including under bounce protection | InboxAssure Platform only |
| Pause Campaigns | Pause and resume campaigns when bounce rates or account disconnections cross the rules in Schedule B | InboxAssure Platform only |
| Spend Placement Credits | Run inbox placement tests, which use credits in Client's EmailGuard account. Once granted, every sending domain in the connected account, including domains added later, is tested automatically each weekday (Monday to Friday) unless it carries the tag “exclude from placement test” in Client's sequencer. Copy placement tests run when Client starts them. | InboxAssure Platform on Client's schedule; the InboxAssure Diagnostic only for a test or fix run Client approves individually, within the test count shown before approval |
| Change Suppression Lists | Add entries to Client's sequencer blacklist | InboxAssure Diagnostic only, and only for a list Client previews and approves |
3.2 A connection grants nothing by itself. Adding an API key lets Company validate the key. It does not grant any of the five permissions. Each permission is off until Client turns it on in the permissions step, and Company records who granted it and when. The InboxAssure Platform cannot run without Read Data and Spend Placement Credits, so Client grants both in the permissions step before payment. The InboxAssure Diagnostic uses Read Data, and asks for Spend Placement Credits or Change Suppression Lists only at the moment Client approves a specific test, fix run, or list.
3.3 Changing permissions. Client may grant or revoke any permission at any time in the dashboard or by written request to billing@inboxassure.app. Company records each change. Revoking a permission stops the related actions but does not cancel the subscription.
3.4 Action log. Company logs every action taken under these permissions, including the time, the account affected, the before and after values, and the test result that triggered it. Client can view or request this log.
3.5 Effect of automated actions. When Change Sending Limits or Pause Campaigns is granted, reduced sending or paused campaigns caused by the InboxAssure Platform operating under Client's recorded settings are the intended function of those permissions.
3.6 Third party accounts and costs. Client is responsible for its own accounts and fees with third party providers. Inbox placement tests are the only part of the Services that use paid credits. Those credits are billed by EmailGuard to Client's EmailGuard account, not by Company, and the number a test uses varies. Company does not charge for, resell, or refund EmailGuard credits. Client controls credit use by tagging domains “exclude from placement test,” pausing tests, declining Diagnostic tests, or revoking Spend Placement Credits.
3.7 Client acts on findings. Where the Services flag an issue, such as a lead already contacted, a removal request, or a suppression gap, Client decides whether and how to act in its own tools, unless a permission under Section 3.1 covers that action.
3.8 Lawful use. Client will comply with CAN-SPAM, applicable state law, the GDPR and similar laws where they apply, and the terms of every connected platform. The Services do not provide legal compliance advice or certification. Company may suspend Services for a violation.
4. Activation
4.1 Activation requirements. A workspace is "Active" for a service line when all of these are recorded:
- (a) the API key is successfully validated, and for the InboxAssure Diagnostic, the InboxAssure placement feed is connected;
- (b) Client confirms the workspace to connect;
- (c) the first data collection completes and passes the completeness checks for that service line;
- (d) the features and permissions in use are recorded;
- (e) Company sends Client an Activation Notice listing the workspace, enabled features with their status, granted permissions, and any known coverage gaps.
4.2 Status shown to Client. The dashboard shows each workspace as Collecting (setup underway, data not yet complete), Blocked (setup or refresh cannot proceed, with the reason), or Active. A workspace is not shown as Active until Section 4.1 is met. If an Active workspace later fails its refresh or completeness checks, the status returns to Blocked with the reason, and saved data stays viewable with its dates.
4.3 Key validation before payment. Company validates Client's API keys before Client can pay or enter the application. A key that fails validation is rejected at signup with the reason. No payment is taken for a failed validation.
4.3A Order form signups. Where Client paid through an order form before its keys were validated, the Billing Start is the date of that payment. If Client's keys cannot be validated within 7 days of payment for a reason other than Client's own delay, and Client cancels within that window, Company refunds the first charge in full.
4.4 Billing Start. After the keys validate, Client pays through Company's checkout, processed by Stripe. The first charge is taken at that moment, the paid period starts at that moment (the "Billing Start"), and Client enters the application immediately after. There is no free or trial period.
4.5 Import during the first period. Company imports Client's data during the first paid period, and the dashboard shows Collecting until Section 4.1 is met. If the workspace is not Active within 48 hours of the Billing Start because of a Company Delay, Company credits the prorated fee from hour 48 until the workspace is Active. A "Company Delay" is any delay except one where Company's log shows, with a timestamp, a failed key, a revoked permission, a disconnected account, or a third party provider outage, and Company told Client of it within 4 hours.
4.6 Blocked setup. If setup is blocked, Company notifies Client with the reason and what is needed.
4.7 Coverage. The Services work from the history Client's connected tools make available and Company retains. Company reports known gaps and does not fill missing data with estimates. A finding labeled incomplete or insufficient is not an all clear.
5. Fees, Billing, and Payment
5.1 Fees. Client pays the fees on the Order Form, in US dollars.
5.2 Recurring billing. The first charge occurs at the Billing Start under Section 4.4. The Services are then billed monthly in advance on that date each month until cancelled under Section 7. Renewal periods are one month.
5.3 Scope of payment authorization. The Payer's authorization covers the recurring fee and any other charges listed on the Order Form at the rates shown there. Company will notify Client before charging any new type of fee.
5.4 Descriptor and reminders. Charges appear on card statements as VITALITY JASON PULLIAM, the merchant name Company uses for all of its businesses. The Order Form, checkout page, welcome email, and every receipt state that name next to the InboxAssure plan. Company sends a receipt for each charge and a reminder 7 days before each renewal to the Purchaser and the Payer. Each receipt and reminder includes a link to the dashboard cancel button.
5.5 Failed payments. If a charge fails, Company's processor retries it 3 times, at 3, 5, and 7 days after the previous attempt (about 15 days in total), and emails the Payer a link to update the card. If the final retry fails, the invoice is past due and Company may suspend the Services after 5 days written notice. Fees for the period remain due while unpaid.
5.6 Taxes. Fees exclude taxes. Company does not currently collect sales tax. If it becomes required, tax appears as a separate line on the invoice.
5.7 Price changes. Company gives 30 days written notice of price changes. Client may cancel before the new price applies.
5.8 Plans and how each is billed.
| Plan | Price | Billed through |
|---|---|---|
| InboxAssure Personal | $300 per month | Stripe subscription |
| InboxAssure Agency | $600 per month | Stripe subscription |
| Fractional Deliverability Expert | Per Order Form | Invoices tied to calendar bookings |
| InboxAssure Diagnostic | Per Order Form, once a Stripe product exists | Not yet sold through Stripe |
5.9 No set off. Fees are payable without deduction or set off. Claims by Client against Company are resolved under Section 12, not by withholding payment.
6. Refunds and Credits
6.1 Refund policy. Fees already charged are nonrefundable, including for partial months, except as stated in this Section or required by law.
6.2 Service credits. If a Company Delay occurs under Section 4.5, or the platform is unavailable for more than 72 consecutive hours in a billing period for reasons within Company's control, and Client reports it in writing within 7 days, Company credits the prorated fee. Credits under Section 4.5 apply without a request. Company applies every credit as a line item on the next invoice, stating the reason and dates, and emails Client when it does.
6.3 Discretionary refunds. Company may issue refunds or credits at its discretion.
7. Cancellation and Suspension
7.1 Software plan. Client may cancel at any time with the cancel button in the dashboard, or by emailing billing@inboxassure.app. Cancellation takes effect at the end of the current paid period. Client can reach the cancel button while suspended.
7.2 Fractional Deliverability Expert plan. Client must give 60 days written notice. Fees remain due during the notice period.
7.3 Effective date of a request. A written cancellation request is effective when received at the address above or through the dashboard. Company will also honor a written cancellation request sent to any Company staff member or support channel, effective on the date sent, and a cancellation stated on a recorded call, effective on the date of the call. Company routes each to billing.
7.4 Confirmation. Company confirms each cancellation by email within 2 business days. The confirmation documents the request; a missing confirmation does not undo a request Client sent. If Client does not receive confirmation, Client should contact Company so the record is complete.
7.5 Records. Company keeps all cancellation and support requests and its responses, whatever they show.
7.6 Suspension. Company may suspend the Services for nonpayment after notice, a violation of Section 3.8, or a security risk.
7.7 Effect of termination. On termination, Company stops all automated actions and revokes its use of Client's keys. Client is responsible for any sending limits it wants changed afterward. Company provides the action log on request for 30 days and may then delete Client Data under Section 11.4.
8. Billing Questions and Disputes
8.1 Contact us first. Client agrees to raise billing questions or complaints with Company at billing@inboxassure.app and give Company 10 business days to respond before disputing a charge with its bank. This does not limit any right Client has under law or card network rules.
8.2 Company's response to a dispute. If Client disputes a charge, Company will respond to the bank with accurate records, which may include this Agreement, acceptance and payment authorization records, Order Form, invoices, reminders, permission records, Activation Notice, action logs, test results, call recordings, and the complete support and cancellation history. Client consents to that disclosure.
8.3 Dispute costs. If a dispute is decided in Company's favor or withdrawn, Client will pay the disputed amount if it was reversed, plus the dispute fee Company's payment processor charged for it. Company invoices these amounts separately and does not recharge the disputed payment method.
8.4 Suspension during dispute. While a dispute is open, Company may suspend the Services. If it does, Company also pauses billing, and resumes both when the dispute closes or Client pays.
8.5 Underlying obligation. A bank's decision on a dispute does not by itself decide whether amounts are owed under this Agreement. Any remaining disagreement may be addressed under Section 12.
9. Disclaimers
9.1 THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE." TO THE EXTENT ALLOWED BY LAW, COMPANY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTY OF RESULTS OR INBOX PLACEMENT.
9.2 Automated and AI outputs. Reply classifications, copy reviews, suggested angles, chat answers, and alerts are produced partly by automated and AI tools. Company checks chat answers against stored data, but checking is not perfect, and the chat cannot answer from data that is not stored. Classifications carry confidence levels and can be wrong. Copy reviews explain and suggest; they are not rewrites, and suggested angles are ideas to test, not a validated ranking.
9.3 Dated reports. Documents, briefings, and reviews are dated records, not a live dashboard. A briefing email that is scheduled may be held when refresh checks fail, and acceptance by an email provider does not prove delivery or reading.
9.4 Marketing materials and case studies are not part of this Agreement.
10. Limitation of Liability
Company is not liable for lost profits, lost revenue, lost data, domain or mailbox damage, or indirect, incidental, special, consequential, or punitive damages. Company's total liability is limited to the fees Client paid in the 12 months before the event giving rise to the claim.
11. Confidentiality, Security, and Client Data
11.1 Company keeps Client's API keys and nonpublic data confidential and uses them only to provide the Services under the granted permissions.
11.2 Company never requests, sends, or stores API keys or private diagnostic data in Slack, email threads, or other chat channels. Keys are entered only in the InboxAssure application.
11.3 Client owns its data. Client's sending, lead, and reply data remains Client's. Company does not share it with other clients. Any learning across accounts requires Client's written permission and uses only anonymized, aggregated data.
11.4 Two kinds of records. "Client Data" means Client's leads, campaigns, replies, and other content imported from Client's tools. "Service Records" means acceptance and payment authorization records, permission records, Activation Notices, action logs, login history (with IP address, device, and user ID), invoices, credits, and support and cancellation history. Company may delete Client Data 30 days after termination. Company retains Service Records for 24 months after the last charge, to answer billing questions and payment disputes.
11.5 Export on request. During the term and for 30 days after termination, Company will provide Client's retained findings, dated reports, and action logs on written request in a common format.
11.6 Data processing. Where Client Data includes personal data of Client's prospects, Company processes it only to provide the Services and on Client's instructions, protects it with reasonable security measures, uses subprocessors only as needed to run the Services, and notifies Client without undue delay after confirming a breach affecting it.
11.7 Company may use anonymized, aggregated operating data to run and improve the Services.
12. Governing Law and Disputes
12.1 Texas law governs this Agreement.
12.2 The parties will try to resolve any dispute through written notice and discussion for 30 days before starting a formal proceeding.
12.3 Venue. Any lawsuit must be filed in the state or federal courts for Brazos County, Texas, and each party consents to their jurisdiction.
12.4 The prevailing party in an action to enforce this Agreement may recover reasonable attorney fees.
13. General
13.1 Entire agreement. This Agreement and the Order Form are the entire agreement. The Order Form controls on conflict.
13.2 No reliance. Client confirms that in deciding to buy, it relied only on this Agreement, the Order Form, and Schedule A, and not on any other statement, website copy, testimonial, sample, call, or demo.
13.3 Changes. Company gives 30 days notice of changes. Changes to price, cancellation, refunds, or disputes apply only after Client accepts them with a new checkbox in the application; Client may cancel instead. Company keeps every version and records who accepted which.
13.4 Other terms. No assignment by Client without consent; severability; no waiver. Sections 5, 6, 8 through 12, and 13 survive termination.
13.5 Existing subscribers. Clients who subscribed before this version keep their current billing date and plan. This version applies to them after 30 days notice and acceptance under Section 13.3. Billing timing rules in Section 4 do not apply retroactively.
Schedule A: InboxAssure Diagnostic Service Description
This schedule applies to every Order Form that includes the InboxAssure Diagnostic. Company updates it when a feature's status changes and keeps prior versions available at this address.
Required sources: a supported email sequencer (currently EmailBison) and the InboxAssure placement feed, both read only. The Diagnostic cannot be used without both.
Permissions used: Read Data. Spend Placement Credits only for a test or fix run Client approves individually. Change Suppression Lists only for a list Client previews and approves.
Included features
| Feature | Status | What Client receives | Limits Client should know |
|---|---|---|---|
| EmailBison history import and preservation | Implemented | A preserved, dated history of campaigns, sends, leads, replies, bounces, inboxes, suppressions, and warmup metrics | Limited to what EmailBison returned and Company retained; archiving in EmailBison can remove attribution |
| Import integrity checks | Implemented | Completeness checks that hold conclusions when data is partial | Detects known gaps; does not certify every answer is complete |
| Registered checks | Implemented | 43 checks across 7 tiers, each reporting Signal, Null, Broken, or Insufficient | A Signal is not proof of cause; Insufficient is not an all clear |
| Audience reuse breakdown | Implemented | Fresh versus repeat contact by campaign and group, with reply counts | Based on retained history, not the whole market |
| List check before upload | Implemented | Per address flags for prior contact, removals, bounces, and blocklist matches | Not SMTP verification, not legal advice, does not write suppressions |
| Reply sentiment classification | Implemented | Tiered classifications with confidence | Positive interest is a proxy, not a meeting or sale |
| Bounce and receiving provider breakdown | Implemented | Bounce reasons and per provider rates on actual sends | Silent spam foldering leaves no bounce |
| Sending domain DNS status | Implemented | DNS status of active sending domains at check time | Not a full SPF or DKIM audit; not permanent reputation |
| InboxAssure placement feed (required) | Implemented | Measured Google and Outlook placement for tested cohorts | Seeds are not all recipients; the Diagnostic does not run or fix tests |
| Warmup measurement | Implemented | Warmup activity and scores as context | Warmup network results are not prospect placement |
| Copy reviews of Email 1 | Published (first test) | Plain English reviews with three angles to explore, linked to teaching | Initial scope only; follow ups not reviewed; not rewrites |
| Historical discovery and saved questions | Implemented | Structured comparisons, kept including null results; account research log | Findings describe this account and period only |
| Account scoped chat | Implemented | Plain language answers checked against stored data | Cannot answer what is not stored; checking is not perfect |
| Dated alerts | Implemented | Severity graded alerts with evidence and next step | Acknowledging an alert records it; it does not mean fixed |
| Briefing page | Implemented | Current week facts and changes | Dated view, not live |
| Customer documents | Implemented | Approved dated reports in Client's documents area | Only reports Company approved for Client |
| Feedback and unanswered question capture | Implemented | A recorded follow up when the system cannot answer | Logging does not guarantee resolution or a response time |
| Mobile view | Implemented, Alerts page only | Usable phone view of alerts | Other pages are built for desktop |
| Placement test on request | Implemented | A single placement test on a chosen inbox and copy, run after Client approves it | Uses Client's EmailGuard credits; result covers the tested inbox and seeds only |
| Copy or domain test | Implemented | A paired test that separates a copy problem from a domain problem | Uses Client's EmailGuard credits; runs only after Client approves it |
| Automatic spam fix | Implemented | On one failing domain, tests the real copy, a plain email, and AI rewritten versions, then adds the signature back step by step until a version lands in the inbox | Runs only after Client approves it; up to 12 tests per run, shown before approval; rewritten copy is a suggestion, never deployed |
| Saved copy versions | Implemented | Copy versions saved to the campaign page with their test results | Saving copy does not change the live campaign |
| Send to blacklist | Implemented | Adds a previewed list of addresses or domains to Client's sequencer blacklist, workspace wide | Runs only after Client sees the count and approves; Client manages removals in its sequencer |
Built but Operationally Blocked (not included or billed until Company gives written notice)
| Feature | Current state |
|---|---|
| Daily briefing email | Held on refresh_incomplete after a storage and checkpoint failure |
| Scheduled production refresh reliability | Storage and checkpoint fix prepared, not yet accepted or deployed |
Not Offered
Deploying or sending campaigns; changing a live campaign's copy; writing to suppression lists or running placement tests without Client's approval; SMTP verification of prospect addresses; revenue, meeting, or ROI attribution; tracking of adopted changes and their outcomes; learning across accounts; a live dashboard.
Schedule B: Client Controls and Company Managed Settings
Client Controls, InboxAssure Platform
| Setting | What Client chooses |
|---|---|
| Domains tested | Every domain in the connected account, except domains tagged “exclude from placement test” in Client's sequencer |
| Sampling | One inbox per domain, or every inbox |
| Schedule | Start date and time, and how many days between runs |
| Waiting time | Hours to wait for seed results before scoring |
| Pass thresholds | Minimum Google and Outlook placement scores, 50% each by default; 0% ignores a provider |
| Sending limits | The daily limit applied when an account fails and when it passes |
| Limit updates | Whether test results change sending limits at all |
| Test copy | Which campaign's copy is used in tests, and whether tests send plain text |
| Pausing a test | Pause or resume any scheduled test |
| New domains | Every domain added to the connected account joins the weekday tests automatically. Client excludes one by adding the tag “exclude from placement test” to it, or stops all tests by pausing them or revoking Spend Placement Credits |
Client Controls, InboxAssure Diagnostic
| Setting | What Client chooses |
|---|---|
| Tests and fix runs | Whether to approve each placement test, copy or domain test, and automatic spam fix run, after seeing the inbox, domain, test count, and credits remaining |
| Blacklist sends | Whether to approve each previewed list before it is added to the sequencer blacklist |
| Copy | Which copy versions to save, and whether to use any suggested copy in a live campaign |
| Alerts | Acknowledge an alert with a note, or reopen it |
| Questions | Which historical questions to save and track |
Client Controls, all service lines
| Setting | What Client chooses |
|---|---|
| Permissions | Grant or revoke each permission in Section 3.1 at any time |
| People | Who acts as Purchaser, Payer, and Connector Operator |
| Subscription | Update the card, view invoices, and cancel through the billing portal |
Company Managed Settings
| Setting | Notes |
|---|---|
| Bounce protection and campaign pause rules | Bounce rate limits, the time window measured, and the disconnection rule. Company sets them and changes them on Client's written request. |
| Seed mailboxes | Which seed inboxes receive placement tests |
| Account health checks | Disconnection monitoring, domain reputation, domain masking, and spam filter checks, and how often they run |
| Data refresh and completeness checks | How often data is collected and the checks that hold conclusions when data is partial |
| Registered checks and reports | The diagnostic checks, alert rules, and report formats |