up:: The Mandates MOC

The Binding-Date Questions

The Binding-Date Questions are a three-question audit that finds an organization’s real post-quantum cryptography deadline inside paperwork it has already signed: what you promised (every agreement, framework, and certification bound to FIPS-validated, NIST-approved, or nationally approved cryptography), where you operate and sell (every jurisdiction the business touches), and what your largest customers will require at renewal. The earliest date the three questions produce is the binding date. For most commercial organizations that date arrives through a contract clause or a certification dependency years before any regulator writes to them, because the mechanism that delivers it is an algorithm changing status on an approved list their obligations already point at.

The short version:

• No regulator letter is coming. The deadline is already in the filing cabinet, inside agreements that reference “FIPS-validated,” “NIST-approved,” or nationally approved cryptography, and each of those inherits the withdrawal date of the list it points at.
• Question 1 is what you promised. Question 2 is where you operate and sell, covering every jurisdiction rather than only the headquarters. Question 3 is what your largest customers will require at renewal.
• The strictest jurisdiction you touch sets your clock: Australian government and defense work means traditional public-key cryptography is out by the end of 2030, UK guidance expects discovery done by 2028, and any product with digital elements sold into the EU carries Cyber Resilience Act obligations from December 11, 2027.
• The earliest date across all three questions wins, and it’s a finish date rather than a start date.
• The binding date is the compliance clock only. It says when you must have fixed it, and it stays silent on when an adversary can read your data; The Two-Clock Test holds both clocks side by side.

Think of an adjustable-rate mortgage. You signed it years ago, the rate is pegged to an index someone else publishes, and when that index moves, your payment moves with it. The bank owes you no new signature and no warning beyond the fine print you already agreed to. A contract that requires “FIPS-validated cryptography” works the same way: the obligation is pegged to an approved-algorithm list a standards body controls, and when RSA-2048 comes off that list, the contract’s meaning changes underneath you with the ink long dry.

What are the Binding-Date Questions?

The Binding-Date Questions are a lookup, run in order, that converts “is post-quantum cryptography mandatory for us?” from an argument into a date:

1. What have you already promised? Pull every agreement, framework, and certification the organization is bound to that specifies FIPS-validated, NIST-approved, or nationally approved cryptography. Each hit inherits the withdrawal date of whatever approved list it points at.
2. Where do you operate and sell? List every jurisdiction the business touches, which is a longer list than the place it’s incorporated. Each jurisdiction contributes its own clock, and the strictest one you touch sets yours.
3. What will your largest customers require at renewal? Enterprise contract language flows downhill, and for many companies the deadline arrives as a customer security clause before any regulator gets involved.

The earliest date the three questions produce is the binding date.

The framework applies to any organization that holds certifications, sells across borders, or serves enterprise or government customers, which in practice covers most companies past a certain size. It has the least to grab when a firm is purely domestic, holds no cryptography-referencing certification, and sells only to consumers; the treatment of that case is below, under where the framework breaks down.

The name describes what the questions find. Nobody has made post-quantum cryptography mandatory for a generic private company, and a vendor who claims otherwise is selling urgency. The obligation that reaches you anyway was signed by your own organization, sometimes a decade ago, and these three questions are how you find it and read the date off it.

Why is no regulator letter coming?

The delivery mechanism for the deadline is indirect, and it works the same way in every jurisdiction that maintains an approved-cryptography list:

1. An algorithm’s status changes on a list you don’t control. In the United States that list is NIST’s approved-algorithm guidance: the draft NIST IR 8547 deprecates RSA-2048 and its 112-bit-security elliptic-curve equivalents after 2030 and disallows them after 2035. Those dates come from an initial public draft and can still shift in the final publication, so quote them as NIST’s stated intent.
2. An obligation you already signed points at that list. FIPS 140 validation is measured against the approved lists, and the federal rule is blunt: FIPS 140-2 and FIPS 140-3 requirements apply to all U.S. federal agencies, and if cryptography is required, it must be validated. Every contract, certification, and framework that says “FIPS-validated” is downstream of that chain.
3. The obligation changes underneath you, and nobody writes a new rule. The day the algorithm leaves the list, an agreement you signed years earlier stops being satisfiable with the cryptography you’re running, and no amendment, letter, or press release is required to make that true.

Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” initial public draft, November 2024, §4; NIST, Cryptographic Module Validation Program, applicability statement.

The European version of the same mechanism runs through product law. The Cyber Resilience Act never names post-quantum cryptography. It requires state-of-the-art protection of confidentiality and security updates across a product’s support period, and “state of the art” moves through harmonized standards: once a harmonized standard is cited in the EU’s Official Journal, conforming to it grants a presumption of conformity. As those standards converge on post-quantum baselines, the working meaning of state-of-the-art confidentiality shifts under every product already on the market, with the regulation itself untouched. Same trap, different list, and on this one the penalties for breaching the essential requirements run to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher.

Source: EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act), official text; European Commission, CRA summary, for the fine ceiling and enforcement powers.

Question 1: what have you already promised?

The working move is a single delegable request to your contracts and compliance teams, in these words: pull every agreement, framework, and certification we’re bound to that specifies FIPS-validated, NIST-approved, or nationally approved cryptography, and list them. Every hit on that list inherits the withdrawal date of whatever approved list it points at, and that becomes a deadline the organization already agreed to.

The clauses hide in predictable places:

1. Government-adjacent contract flow-downs. DFARS 252.204-7012 requires covered defense contractors to implement NIST SP 800-171 on any system handling covered defense information, and SP 800-171 Revision 2 carried the requirement verbatim at 3.13.11: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” Revision 3 (May 2024) restructured that control as an organization-defined parameter with FIPS-validated cryptography recommended in the discussion, so the exact obligation now depends on which revision your contract invokes; either way, the clause points your cryptography at NIST’s lists.
2. Cloud certifications. FedRAMP states the rule plainly in its cryptographic-module policy: the use of FIPS 140 validated cryptographic modules where encryption is required is a federal mandate. Hold a FedRAMP authorization and your product’s cryptography is pegged to the FIPS approved lists for as long as you keep it. Australia runs the equivalent through IRAP, where ASD-endorsed assessors evaluate systems against the Information Security Manual, the same rulebook that retires traditional asymmetric cryptography at the end of 2030.
3. Payment standards. PCI DSS defines “strong cryptography” as industry-tested and accepted algorithms with a minimum of 112 bits of effective key strength, and points implementers at NIST SP 800-57 Part 1 for key-strength guidance. A definition that leans on NIST’s key-strength guidance inherits NIST’s schedule for when 112-bit public-key security stops being acceptable.
4. Federal customers and contractor-operated systems. OMB M-23-02 put every federal civilian agency on an annual cryptographic-inventory cycle and reaches contractor-operated systems explicitly, with accountability the agency cannot delegate to the vendor. Operate a system on an agency’s behalf and its inventory obligation is already yours.
5. The product validations themselves. A FIPS 140-3 certificate is earned against the approved-algorithm lists, so an algorithm leaving the list eventually reaches the certificate and the products whose sales depend on it.

Sources: DFARS 252.204-7012(b)(2)(i), acquisition.gov; NIST SP 800-171 Rev. 2, requirement 3.13.11, SP 800-171r2 PDF; NIST SP 800-171 Rev. 3, requirement 03.13.11 and discussion, SP 800-171r3; FedRAMP, Policy for Cryptographic Module Selection and Use v1.1.0; ASD, Infosec Registered Assessors Program (IRAP); ASD, “Guidelines for cryptography,” Information Security Manual, cyber.gov.au; PCI SSC, glossary entry for Strong Cryptography; OMB, “Migrating to Post-Quantum Cryptography,” M-23-02, November 18, 2022, M-23-02 PDF; NIST, Cryptographic Module Validation Program.

The output of Question 1 is a list of obligations, each annotated with the approved list it depends on and the date that list changes. For anything pointing at the NIST chain, the draft schedule is deprecation of RSA-2048-class cryptography after 2030 and disallowance after 2035, held with the draft-status hedge until NIST IR 8547 is final.

Question 2: where do you operate and sell?

Jurisdiction is decided by where the business operates and sells, which is a longer list than where it’s incorporated. A company headquartered in Delaware with a subsidiary selling into the EU and a support contract with an Australian government department is running three clocks at once, and it inherits the earliest.

This is the extractable version of the landscape. Every scope qualifier in the table is load-bearing: widen any of these mandates past its stated audience and the claim becomes false.

Jurisdiction	Instrument	The dates	Who it binds	Statutory or advisory
United States, federal civilian	EO 14412 (June 22, 2026)	Key establishment by Dec 31, 2030; digital signatures by Dec 31, 2031	Federal civilian executive-branch systems; excludes national security systems	Binding executive order
United States, national security systems	CNSA 2.0 (Sept 2022; FAQ updated Dec 2024)	Required in new NSS acquisitions from Jan 1, 2027; mandated for all NSS by Dec 31, 2031	National security systems and the vendors selling into them	Binding NSS policy
United States, algorithm schedule	NIST IR 8547 (initial public draft, Nov 2024)	RSA-2048-class (112-bit security) deprecated after 2030, disallowed after 2035	Federal systems directly; anyone bound to FIPS-validated or NIST-approved cryptography indirectly	Draft guidance; bites through FIPS validation
United States, inventory	OMB M-23-02 (Nov 18, 2022)	Annual cryptographic inventory, due every year since May 2023	Federal civilian agencies, including contractor-operated systems	Binding OMB memo
United States, policy goal	NSM-10 (May 4, 2022)	Mitigate as much quantum risk “as is feasible” by 2035	Federal agencies	Policy goal with the hedge written into the sentence
Australia	ASD Information Security Manual	Transition plan by end 2026; critical systems commenced by end 2028; traditional asymmetric cryptography out by end 2030	Australian government, defense, and suppliers handling PROTECTED-level data; assessed via IRAP	Government baseline the systems are assessed against
United Kingdom	NCSC migration timelines (Mar 20, 2025)	Discovery and migration plan by 2028; highest-priority migrations by 2031; all systems by 2035	Advisory for all UK organizations; CNI, finance, and telecom are measured against it by customers and regulators	Advisory
European Union, product law	Cyber Resilience Act (Reg. (EU) 2024/2847)	Reporting obligations from Sept 11, 2026; full obligations from Dec 11, 2027	Any manufacturer worldwide placing a product with digital elements on the EU market	Binding regulation; names no algorithm and sets no PQC date
European Union, PQC dates	Coordinated Implementation Roadmap (June 2025)	Start by end 2026; high-risk use cases on PQC by end 2030; complete by 2035	Addressed to member states	Recommendation; force arrives downstream through supervision and the CRA’s harmonized standards

Sources: The White House, EO 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” June 22, 2026, whitehouse.gov and 91 FR 38483, federalregister.gov; NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022, and CNSA 2.0 FAQ, December 2024 update; NIST IR 8547 ipd, §4; OMB M-23-02, M-23-02 PDF; NSM-10, May 4, 2022, bidenwhitehouse.archives.gov; ASD, “Guidelines for cryptography,” Information Security Manual, cyber.gov.au and “Planning for post-quantum cryptography,” cyber.gov.au; NCSC, “Timelines for migration to post-quantum cryptography,” March 20, 2025, ncsc.gov.uk; EUR-Lex, Regulation (EU) 2024/2847, official text; European Commission, “A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography”.

Three readings of that table earn their keep:

1. Three regimes converge on 2030. The U.S. federal civilian key-establishment date, Australia’s full exit from traditional asymmetric cryptography, and the EU roadmap’s high-risk migration target all land at the end of 2030, arrived at independently, 5 years ahead of the 2035 in the headlines.
2. The most-quoted date is the softest. NSM-10’s 2035 is a goal with “as is feasible” written into the operative sentence. The dates with teeth sit earlier and in more specific instruments.
3. Advisory guidance still shows up in your renewals. Nobody fines a UK firm for missing the NCSC’s 2028 discovery milestone, and UK critical-infrastructure, finance, and telecom buyers map their vendor expectations to it anyway, which converts an advisory date into commercial pressure with the same arrival time.

Question 3: what will your largest customers require at renewal?

Enterprise contract language flows downhill. A bank bound to a regulator’s cryptography expectations passes an equivalent requirement into its vendor security addenda; a defense prime bound by DFARS flows SP 800-171 into every subcontract that touches covered defense information, per the flow-down requirement in the clause itself; a cloud customer bound by FedRAMP asks its own suppliers for FIPS-validated modules because its authorization depends on them. Each hop happens at contract renewal, which is why the deadline so often lands on a commercial calendar rather than a regulatory one.

Source: DFARS 252.204-7012(m), subcontract flow-down. ⚠️ The trailing period is part of the URL on acquisition.gov and must not be stripped: with it the page returns 200, without it 404. Mirror without the quirk: ecfr.gov. acquisition.gov.

The clause rarely says “post-quantum.” It says the vendor will maintain encryption consistent with industry standards, applicable law, or a named framework, which is the same pointer mechanism in private form: the customer’s obligation references a list, your contract references the customer’s obligation, and the date propagates through two hops of paperwork. The practical consequence is that Question 3 belongs to the sales and account teams as much as to security, because they are the people who see the security addendum redlines at renewal and can flag a cryptography clause the security team would never hear about until it was signed.

What does running the three questions actually look like?

A worked example, on a deliberately generic multinational. Picture a software and device manufacturer incorporated in the United States: it sells a connected industrial product into the EU, operates a FedRAMP Moderate SaaS offering for U.S. agencies, takes card payments inside PCI DSS scope, holds a support contract with an Australian government department that handles PROTECTED-level data, and counts a UK bank as its largest customer.

1. Question 1, what was promised. The pull request comes back with the FedRAMP authorization (FIPS 140 validated modules, a federal mandate under the FedRAMP cryptographic-module policy), a DFARS 252.204-7012 flow-down from one defense-adjacent contract (SP 800-171, with its FIPS-validated cryptographic-protection control), and the PCI DSS obligation (strong cryptography per NIST key-strength guidance). All three point at NIST’s lists, so all three inherit the draft IR 8547 schedule: RSA-2048-class deprecated after 2030, disallowed after 2035, dates held with the draft hedge.
2. Question 2, where it operates and sells. The EU product line puts it under the Cyber Resilience Act from December 11, 2027, wherever it’s headquartered. The Australian support contract sits inside ISM scope, which means the end-2028 critical-systems milestone and the end-2030 exit from traditional asymmetric cryptography. The UK footprint carries advisory weight only, and the bank measures its vendors against the NCSC’s 2028 discovery milestone anyway.
3. Question 3, what the customers will ask. The bank’s vendor security review runs on a renewal cycle, and the realistic shape of the next one includes a question about cryptographic inventory and a migration plan, because the bank itself is being measured against the NCSC timeline. (The shape is illustrative; the date on any real renewal comes from the contract calendar.)
4. Take the earliest. The candidate dates are December 11, 2027 (CRA full obligations), 2028 (NCSC discovery, arriving via the bank), end 2028 (ISM critical-systems milestone), end 2030 (the ISM exit, plus the key-establishment date its U.S. agency customers must meet under EO 14412, which reaches the SaaS product through federal procurement), and 2035 (IR 8547 disallowance). The binding date is December 11, 2027, and it belongs to the product line, which is the part of the company nobody in the security organization was watching.

The last line of that example is the recurring finding. The binding date usually attaches to a specific business surface, a product line, a certification, a single large account, rather than to the company as a whole, and the surface it attaches to is often owned by a team that has never heard of post-quantum cryptography.

How do the Binding-Date Questions relate to the Two-Clock Test?

The three questions produce Clock 1 of The Two-Clock Test: the compliance clock, the date by which an authority or a contract requires the fix. Clock 2, the threat clock, is the date an adversary can read what a system protects, and it comes from exposure reasoning, Mosca’s Theorem and the harvest-now-decrypt-later window, rather than from any filing cabinet. The two clocks measure different things, and every mandate in the table above was set against quantum-timeline estimates that keep moving, which is why an organization can be fully compliant and fully exposed on the same day. Run the Binding-Date Questions to get the date you owe someone else; run the threat-clock math to get the date you owe yourself; plan to the earlier of the two.

How do you use the binding date in the boardroom?

The binding date’s boardroom value is that it converts a technology argument into a contractual fact, and contractual facts are the board’s native language:

1. State it as an inherited obligation. The sentence is: “Our binding date is [date]. It comes from [instrument or clause], we agreed to it in [year], and it applies whether or not any regulator ever names us.” That framing survives the “is this vendor fear-mongering?” objection, because the evidence is the organization’s own signature.
2. Give it a row in the risk register. The binding date and the threat date are separate rows in The Cryptographic Risk Register, each with its own source and owner, so the register stops flattening two different clocks into one vague “quantum risk” line.
3. Answer the 2035 quote with the table. When someone senior quotes 2035, the response is the strictest-jurisdiction reading: 2035 is a hedged U.S. policy goal, the organization’s own paper points at 2030 and the EU product line at 2027, and the earliest instrument wins.
4. Plan backward from it. These are dates by which the work must be finished. A 2030 obligation with a multi-year migration behind it is a start date in the past, and presenting the binding date next to the migration lead time is what turns it into a funded program rather than a noted risk. Brief Your Board carries the fuller version of that conversation.

Where do the Binding-Date Questions break down?

Published limits, because a framework worth trusting shows you exactly where it fails:

1. Purely domestic, uncertified, consumer-only firms. A company that operates in one country, holds no cryptography-referencing certification, and sells to no enterprise or government customer gives the mechanism nothing to grab. All three questions come back empty, and that’s a true answer rather than a failure: no binding date exists yet for that firm, and its only clock is the threat clock.
2. The date it finds is a compliance date. The questions say when you must have fixed it and say nothing about whether harvested data is already exposed. An organization holding data that must stay confidential into the 2030s can have a comfortable binding date and an expired threat clock at the same time.
3. The search is real work at scale. The questions tell you what to look for, and a 10,000-contract estate stays a 10,000-contract estate. Large organizations end up sampling by contract value and jurisdiction, and a sampled answer carries sampling risk.
4. Shared-responsibility blur. When the FIPS-validated obligation attaches to a cloud provider’s certification, the provider owns the module validation while you still own the data-layer cryptography and the contractual promise, and the questions surface the date without resolving that boundary for you.
5. The answer has a shelf life. A new market entry, an acquisition, a new certification, or IR 8547 going final can each move the binding date overnight, so a date found once and filed is a date that quietly goes stale.

Common misconceptions

1. “Our headquarters’ rules set our deadline.” The strictest jurisdiction you touch sets it. A Delaware company with an EU product line and an Australian government contract runs three clocks and inherits the earliest.
2. “Advisory guidance can be ignored.” The NCSC timeline carries no fines, and UK critical-infrastructure, finance, and telecom buyers measure their vendors against it anyway, so the advisory date arrives through renewals with near-statutory force.
3. “The CRA is an EU problem and we’re not an EU company.” The Cyber Resilience Act binds any manufacturer worldwide that places a product with digital elements on the EU market. Headquarters location is irrelevant to its scope.
4. “The deadline is 2035.” 2035 is NSM-10’s hedged policy goal (“as is feasible”) and the outer edge of several national roadmaps. The instruments with teeth land earlier: 2027 for CRA obligations and new NSS acquisitions, 2028 for UK discovery and Australian critical systems, 2030 for U.S. federal key establishment and Australia’s full exit.
5. “A deadline is when we start.” Every date in the table is a completion date. A 2030 finish with a multi-year migration behind it puts the start date in the past, which is the arithmetic that makes the binding date urgent rather than distant.
6. “No letter means no obligation.” The mechanism never sends letters. An algorithm changes status on a list, an agreement you signed points at the list, and the obligation lands with the paperwork already years old.
7. “IR 8547 is a draft, so we can wait for the final.” The dates deserve the draft hedge, and the direction is already propagating: procurement language, agency planning, and vendor roadmaps are being written against the draft schedule now, so waiting for finality means inheriting other people’s interpretation of it at renewal time.
8. “Our cloud provider’s FedRAMP authorization covers us.” The provider’s authorization covers the provider’s modules. Your application-layer cryptography, your key management above the module boundary, and every promise in your own customer contracts stay yours.

Pro tips

1. Route Question 2 through general counsel, framed as a legal-exposure question. Which jurisdictions can enforce an obligation against us, and through what instrument, is a legal determination, and a security team asked to answer it will guess. Counsel treating it as exposure analysis produces the defensible list.
2. Make Question 3 the sales team’s problem. Account teams see the security addendum redlines at renewal months before security does. Ask sales operations to flag any renewal language touching encryption, certification, or “applicable security standards,” and the commercial side of the house starts carrying the watch for you.
3. Run Question 1 as a verbatim, delegable request. The exact words matter because they’re greppable: “every agreement, framework, and certification we’re bound to that specifies FIPS-validated, NIST-approved, or nationally approved cryptography.” Hand that sentence to contracts and compliance and the search runs without you.
4. When the first answer is evasive, ask which list. A vendor or an internal team claiming “we’re compliant” gets the follow-up: “Which approved list does that validation point at, and what happens to that list after 2030?” The question is answerable only by someone who actually understands the dependency, which is the point.
5. Give the binding date a trigger list, and re-run on triggers rather than on a calendar. New market entry, an acquisition, a new certification, a major customer renewal, IR 8547 going final, and the first harmonized standard with post-quantum content cited in the EU’s Official Journal each invalidate the previous answer.
6. Record the clause, never just the date. A risk register row reading “Dec 11, 2027, CRA Art. 13 obligations, EU product line” survives staff turnover and audit questions; a bare date invites relitigating the whole analysis next budget cycle.
7. Ask vendors for their binding date. A vendor roadmap that can’t name the instrument it’s answering to is a roadmap built on marketing rather than obligation, and the question costs you one sentence in the next QBR.

Questions people ask

Is post-quantum cryptography actually mandatory for my company? If you’re a U.S. federal agency, a national-security-system operator, in scope for Australia’s ISM, or placing products with digital elements on the EU market, a binding instrument already names you. For everyone else, the answer is that no regulator has made it mandatory, and the Binding-Date Questions exist because the obligation usually arrives anyway, through certifications, contracts, and customers, on a date you can look up.

What if all three questions come back empty? Then no binding date exists for you yet, and that’s a legitimate result. Your remaining clock is the threat clock: if you hold data whose confidentiality must outlast the arrival of a cryptographically relevant quantum computer, the exposure math of The Two-Clock Test still applies even though no paperwork does.

Which question usually produces the earliest date? For manufacturers selling into the EU, Question 2, because the CRA’s December 11, 2027 obligations date leads the field. For U.S. government-adjacent firms, Question 1, through the FIPS-validation chain. For everyone else it’s most often Question 3, because enterprise renewal cycles run continuously while regulations arrive in discrete steps.

Is the UK guidance really binding if it’s advisory? It’s advisory, and nobody will fine you for missing it. Its practical force comes from UK critical-infrastructure, finance, and telecom buyers mapping vendor expectations to its 2028, 2031, and 2035 milestones, which means the date reaches you through a customer questionnaire rather than a statute.

Does the CRA give me a post-quantum deadline? It gives you an obligations date, December 11, 2027, and it never names post-quantum cryptography. Its state-of-the-art confidentiality requirement and support-period update obligation are what pull post-quantum readiness into EU market access over time, through harmonized standards, so treat the CRA date as the day your product’s cryptographic update path has to be real rather than the day PQC becomes required.

What does “disallowed” mean for products we’ve already validated? In NIST’s vocabulary, deprecated means still permitted with formally accepted risk, and disallowed means prohibited for the stated purpose. When an algorithm your FIPS validation relies on becomes disallowed, agreements requiring FIPS-validated cryptography stop being satisfiable by that configuration, which is the moment the contract clause becomes a migration obligation. The current schedule (deprecation after 2030, disallowance after 2035 for RSA-2048-class algorithms) is draft and can shift.

How often should we re-run the questions? On triggers rather than a schedule: entering a market, closing an acquisition, gaining a certification, a major renewal, IR 8547 finalizing, or post-quantum content landing in a harmonized standard. Absent triggers, an annual pass alongside the risk-register review keeps the date honest.

Who should own the binding date once it’s found? Give the date a single accountable owner in the risk function or the CISO’s office, with the sourcing distributed: counsel owns the jurisdictional analysis, contracts owns the Question 1 list, and sales operations owns the renewal watch. The failure mode is everyone assuming compliance is tracking it, when compliance tracks the frameworks rather than the dates inside them.

---

Everything here is the map, given freely. The three questions tell you where your binding date lives; reading your whole contractual and regulatory surface across every market you sell into, and turning the earliest date into a sequenced program, is the work I do. When your team wants this run against your own estate, that’s the work I do.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.