When OpenCTI customization becomes necessary and who should do it
Customization becomes necessary when a threat intelligence team has a working OpenCTI deployment but the platform does not yet match how analysts collect, relate and act on intelligence. In most organizations, simple settings are handled in-house by the platform administrators and analysts who own the daily work, while connector development, changes that depend on Enterprise Edition features and any change that must survive future upgrades are better planned with an implementation partner. The line between these groups is set by the type of change, not by how urgent it feels.
The most common triggers are new feeds, internal data sources, analyst workflow gaps and reporting needs. A new commercial or community feed may require a connector that maps its records to STIX2 objects and relationships. An internal source, such as an incident ticketing system or a case register, usually needs an import path and a decision about which entities and marking definitions it produces. Workflow gaps appear when analysts repeat the same enrichment or triage steps by hand, and reporting gaps appear when leadership asks for views that the default dashboards and workspaces cannot produce.
Before any change is requested, the team should write down what the change touches. OpenCTI structures its data with a knowledge schema based on the STIX2 standards and exposes the web application and its data through a GraphQL API. Custom connectors, entity settings, dashboards and automation should be planned against that schema and API, because they determine which objects are created, how they are related and which fields other tools can read. A change that edits data structures without reference to the schema tends to create records that other connectors, exports or queries cannot interpret.
Ask each candidate change three questions. Does it need a feature that is licensed under the Enterprise Edition, such as playbooks or organization-based data segregation? Does it add or alter a connector that writes to the platform through the workers? Will it need to be retested when the platform moves to a new release? Changes that answer yes to any of these need a written design, a named owner and a test plan before implementation. Changes that answer no can usually be made by an administrator, provided they are recorded and reversible.
Confirm early which Enterprise Edition features your licence covers, which release line you will run, and who on your side owns schema decisions, since these answers change who should build each item. Ask any partner to separate the in-house items from the partner items in the written scope, and to state how each custom component will be tested against upcoming releases. Those answers determine whether customization stays manageable as the platform evolves.
What OpenCTI customization includes and what you receive
Customization work usually touches the connector layer, the data model, and the analyst-facing views, and each change has to survive the next OpenCTI release. The cards below cover the work packages we scope, the controls that keep them compatible with a fast release cadence, and the written artifacts you keep after handover.
Custom connector development
We build import, enrichment or export connectors on the pattern OpenCTI uses: a connector process publishes work to RabbitMQ, and Python workers consume those messages and write to the platform asynchronously. Before scoping, confirm the source's data format, rate limits, and how it maps to STIX2 objects. Ask how each connector is sized against worker capacity and how duplicate objects are handled.
Playbook design where supported
Playbooks automate steps such as enrichment, assignment, or routing of intelligence. Playbooks are an Enterprise Edition feature, so the scope starts with confirming the license tier you hold. We document each playbook's trigger, the entities it reads and writes, and the failure path when a connector is unavailable. Ask for a list of playbooks that will not run without Enterprise Edition.
Entity and relationship settings
We adjust which entity types, attributes, and relationship types analysts see and can create, so the model reflects how your team works with STIX2 objects. Changes are made in configuration where the platform supports it and recorded individually. Check which settings affect existing data, since changing a definition after ingestion can change how older records appear.
Dashboards, saved views and workspaces
We build dashboards, saved filters, and workspaces for the queries your analysts run daily, such as campaign tracking or sector views. Each view is tied to the data model it depends on, so a later schema change can be traced to the affected views. Confirm who owns each shared view and who may edit it, because shared objects are visible to every user with access.
Upgrade-safe change control
Every customization is kept in version control with a record of what changed, why, and which OpenCTI version it was tested against. Non-LTS releases ship from daily to weekly, and LTS lines carry their own license key and support window, so each change is re-tested before a version move. Ask how your team will be notified of breaking changes and who approves a release that touches custom code.
Handover documentation and test evidence
At handover you receive the written artifacts: connector code and configuration, a change log, runbooks for operating and rolling back each customization, and test results from the agreed test cases. The exact list of deliverables is fixed in the written scope before work starts. Ask for the test environment definition and the pass criteria, so the evidence can be reproduced by your own team.
What drives OpenCTI customization cost and duration
This table lists the factors that change how much work an OpenCTI customization takes and how long it runs, with a note on how to keep each one under control. Read each row as a question to answer before requesting a quote, because the answers set the scope. The main takeaway is that connector count, analyst segregation needs and environment count usually move cost more than any single code change.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of custom connectors and data sources | Each connector needs its own mapping, error handling, testing against the live feed and ongoing maintenance as the source changes. | Confirm which feeds carry real analyst value, reuse existing connectors where they fit, and phase custom builds rather than starting them all at once. |
| STIX2 object types involved | Custom entities, relationships or observables must follow the STIX2-based knowledge schema, and each new type touches imports, exports, queries and dashboards. | Start from the standard STIX2 objects, limit custom types to documented gaps, and record every schema change in one place. |
| Analyst groups and organizations needing separate views | Separate views depend on organization-based data segregation, which is an Enterprise Edition feature, and each group adds roles, permissions and test cases. | Define a small set of groups from real access needs, map them from existing identity groups, and avoid one-off permission rules. |
| Enterprise Edition features in scope | Playbooks, activity monitoring and audit logs, SSO configuration and other Enterprise Edition features add licensing decisions and configuration work on top of customization. | Confirm the license scope early, list only the features the analysts need first, and leave optional features for a later phase. |
| Number of environments (dev, test, production) | Each environment needs its own deployment, connector set, data and validation runs, so changes must be promoted and checked more than once. | Keep environments as close in configuration as possible, automate deployment, and use a small test dataset that reflects production shapes. |
| LTS or continuous release line in use | Continuous releases ship from daily to weekly, so customizations may need retesting often, while LTS releases need a license key and receive only critical bug and security fixes after stabilization. | Choose the release line before design begins, pin versions per environment, and schedule upgrade tests as recurring work. |
| Compliance evidence requirements | Assessors may ask for configuration records, access reviews, audit logs and change history, which the team must design and document alongside the customization. | Agree the evidence list at scoping, build logging and change records into the work, and confirm exact requirements with your assessor. |
| Quality of the source data and mapping rules | Messy source records require normalization rules and exception handling that often exceed the effort of the connector code itself. | Profile a sample of source data before scoping, agree mapping rules in writing, and decide which records are out of scope. |
Keeping OpenCTI customizations compatible with a fast release cadence
The first decision is which release line your customizations will be built and tested against, because that choice sets how often they must change. OpenCTI regular releases use the pattern x.YYMMDD.z, where the date is the release or LTS branching date. For example, 7.261016.0 was published on October 16, 2026. Non-LTS releases ship when they are ready, from daily to weekly, so a custom connector or dashboard built on that line may face several platform changes in a single month. Customizations that depend on the GraphQL API, the STIX2-based knowledge schema or connector interfaces are the ones most exposed to that churn, so they need a deliberate plan before they go into production.
LTS releases are the alternative. They arrive about every six months, each is supported for one year, and consecutive LTS versions overlap by six months, which gives you time to move. Two conditions matter for customization work. LTS releases require a specific LTS license key, so confirm who holds that key and how it is renewed before you commit a team to that line. After a one-month stabilization period, LTS releases receive only critical bug and security fixes, so feature changes that your customizations rely on will not arrive on that line. The 7.260309.0 LTS line had reached hotfix lts.8 by October 2026, which shows how many maintenance increments a single line can accumulate.
Whichever line you choose, customizations that touch the API, schema or connector interfaces need regression testing against each target release. Build a suite that covers every custom component: the GraphQL queries and mutations your scripts issue, the entity types and custom attributes your schema extensions add, the message handling of any custom connector, and any playbook steps that depend on platform behavior. Feed it fixed sample STIX2 bundles so that results are comparable from one release to the next. The suite should also run against the connector versions you actually deploy, since connector and platform changes can interact. Keep the results with the release identifier so that a failure can be traced to a specific change.
Pin a tested version of the platform and of each custom connector in your deployment manifests, and record which customizations were verified against it. Do not let a container tag such as latest move forward on its own. Before any upgrade, deploy the next candidate build to a non-production environment that mirrors your dependencies, run the regression suite, and review the results with the people who own each customization. Then read the release notes for your chosen line, checking the API and connector compatibility notes for every version in the path. Confirm those notes with the vendor if they are unclear, and do not assume that a note written for a daily build also applies to your LTS line.
How an OpenCTI customization project runs, phase by phase
The sequence moves a customization from analyst needs to a tested, documented change in production, with each phase producing a named artifact that the next phase depends on. It keeps custom connectors, entity settings and dashboards compatible with the release line you run.
Map analyst workflows and data sources
The engagement lead works with the analysts who use the platform daily to document how intelligence arrives, how it is triaged, enriched, related and shared, and which tools it moves between, such as MISP or TheHive. The owner is the DeployOpen engagement lead with your analyst lead, and the artifact is a workflow inventory listing each source, its format, its owner and the pain points to fix. The phase is complete when your analyst lead signs off that the inventory matches how the team actually works, not only how it is documented.
Design the entity and access model
The solution architect turns the inventory into a design for custom entity types, relationships, marking definitions, organizations and group-based access. Where a requirement depends on Enterprise Edition features such as organization-based data segregation, playbooks or priority intelligence requirements, the design records that dependency and the license it needs. The artifact is a design document with a data model diagram, an access matrix and a compatibility note for the release line you will run. The phase closes when your security and data owners approve the access matrix.
Check compatibility with the release line
Before any build starts, the platform engineer confirms that the planned schema changes, custom connectors and API calls work on the exact OpenCTI version you run. Regular releases ship on a fast cadence, while LTS releases receive only critical bug and security fixes after stabilization, so the check depends on which line you choose. The artifact is a compatibility record that names the version, the connector library versions and any API behavior to watch. This check repeats at each upgrade, so it is recorded as a standing item.
Build connectors and configuration in non-production
The engineers build custom connectors, playbook settings, dashboards and workspaces in a non-production instance that mirrors your production dependencies: the platform, Python workers, RabbitMQ, Redis, Elasticsearch or OpenSearch, and object storage. Changes are kept in version control so each one can be reviewed and reverted. The artifact is a tagged build with a change list and a deployment script. The phase is complete when the non-production instance runs the full set of connectors and the build reproduces from the repository without manual steps.
Test against a copy of representative data
The test lead loads a copy of representative data into the non-production instance, drawn from the sources in the workflow inventory, and runs the analyst workflows end to end. Tests cover import and deduplication, entity relationships, access restrictions for each group, worker queue behavior under load and dashboard accuracy. Production data is used only where your data governance rules allow it, and otherwise a sanitized copy is used. The artifact is a test report that lists each case, the result and any defects with their owners. Sign-off requires that no open defect blocks an analyst workflow.
Roll out in production under change control
The release manager schedules the production change through your change process and attaches the tested build, the test report, the rollback steps and the compatibility record. The platform engineer applies the change in the agreed window, validates each connector and access rule, and watches queues and worker health after the change. The artifacts are a change record with start and end times, a validation checklist with results and a rollback plan that was confirmed before the window opened. The phase closes when your change authority approves the post-change validation.
Hand over with runbooks and training
The DeployOpen team walks your operations and analyst leads through the solution and supplies runbooks for routine tasks, connector failures, queue backlogs, access requests and the compatibility check needed before the next upgrade. The team also records which items remain your responsibility after handover and which are covered by a support agreement. The artifacts are the runbook set, the architecture and data model documentation and a handover log signed by your operations lead. Handover is complete when your team has run at least one routine task from the runbooks without assistance.
What usually goes wrong in OpenCTI customization projects
Most OpenCTI customization problems do not show up during the build. They appear after the next platform release, when a connector backs up the queue, or when someone leaves the team and nobody knows how a custom piece works. Each card below names one failure mode, the early check that prevents it, and what to confirm before work starts.
Building against an unstable version
Customizations written against a moving target such as a non-LTS daily or weekly build can break on the next release, since OpenCTI uses date-based versions (x.YYMMDD.z) and non-LTS releases ship frequently. Pin the target version in the project scope, record it in the build notes, and confirm whether the client will run the regular release line or an LTS line with its own license key before any custom code is written.
Connectors that flood the queue
A connector that imports a large feed without limits can fill RabbitMQ and starve the Python workers that handle asynchronous writes, so analysts see delays rather than errors. Set batch sizes and run intervals per connector, size worker capacity against the connectors enabled, and watch queue depth during a trial import. Duplicate feeds across connectors are a related risk, so confirm which source is authoritative for each entity type.
Schema changes that break relationships
Custom entity types, attributes or relationship rules change how STIX2-based data is stored and queried, and existing imports, connector mappings and dashboards may depend on the old structure. Before changing the schema, list every connector, playbook and saved view that reads the affected types, and test the change on a copy of production data. Treat schema edits as versioned changes with a rollback plan, not as quick settings changes.
Access rules exposing data to the wrong group
Custom roles, groups and organization-based segregation decide who sees which intelligence, and a misconfigured rule can expose sensitive reports to a partner group without any visible error. Map each group to the data it should reach, test access with a sample account per group, and schedule a periodic review of group membership. Confirm early whether organization-based data segregation is in the licensed feature set, because it is an Enterprise Edition capability.
Playbooks relying on unlicensed features
Playbooks are an OpenCTI Enterprise Edition feature, so a workflow designed on a trial or development license may stop working when the license lapses or when the production tenant is set up on Community Edition. Before design, list every feature each playbook uses, such as SSO-linked roles, audit logging or playbook triggers, and check each one against the license the client has actually purchased. Ask the vendor to confirm license scope in writing.
Custom code with no owner
Custom connectors, scripts and dashboards often run for years after the project team leaves, and when a connector fails or an upgrade breaks it, nobody knows who can fix it. At handover, name a technical owner for each custom component, store source and configuration in version control, and write a short runbook covering how it is deployed, monitored and tested after a platform upgrade. Ask whether ongoing support or a retainer will cover these components.
Which parts of OpenCTI customization your team keeps and which to outsource
This table compares six parts of OpenCTI customization by usual owner, the skills each needs and the reason for that split. Read it as a starting point: the right split depends on your analysts' existing skills and how much staff time you can give to custom code over the life of the platform.
| Work part | Usual owner | Skills needed | Why |
|---|---|---|---|
| Analyst workflow definition | In-house | Threat intelligence process, STIX2 concepts, analyst team leadership | Only your analysts know which entities, relationships and review steps match how they triage and report intelligence. |
| Entity and dashboard configuration | Often in-house, with vendor training | Familiarity with the OpenCTI interface, data model and dashboard widgets | Configuration is reversible and changes with the team, so keeping it close to analysts speeds iteration. Confirm training options with Filigran. |
| Custom connector development in Python | Partner or in-house with Python and API skills | Python, GraphQL API, STIX2 object modeling, connector testing, message queue behavior | Connectors run as separate workers and write to the platform through its API, so errors can affect data quality and worker capacity. |
| Enterprise feature configuration | Depends on licensing | Enterprise Edition administration, identity and access design, audit log review | Features such as SSO, playbooks and organization-based segregation require an Enterprise license. Confirm your entitlements before planning the work. |
| Release testing and upgrade regression | Shared | Test automation, connector regression testing, release notes review, staging environment operation | Continuous releases can change behavior that custom connectors and dashboards depend on, so both your team and the implementation partner need to test. |
| Long-term maintenance of custom code | Decide who owns it before build starts | Code review, version control, dependency updates, documentation and handover | Custom connectors and queries need updates for each platform change. Without a named owner, they tend to fall behind the release cadence. |
Recurring costs after OpenCTI customizations go live
After go-live, costs continue in five places: keeping custom connectors compatible with new releases, licensing the features you depend on, running the workers that execute connectors, and reviewing their output. Each item recurs, and each depends on choices made during customization. Confirm current licensing terms and any fees with Filigran or in the vendor documentation, because this page does not state prices.
Custom connector maintenance
Custom connectors depend on the platform's API and worker interfaces, so a new OpenCTI release can change behavior your code relies on. Plan regression testing against each release you intend to deploy, along with updates to connector libraries and configuration. Whoever owns the connector code owns this work. Confirm who will hold it, how often releases are reviewed, and how urgent fixes are handled.
Enterprise Edition license fees
The Community Edition is licensed under Apache License 2.0. The Enterprise Edition is proprietary, governed by the OpenCTI Enterprise Edition License, and adds features such as playbooks, audit logs and SSO. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition. Map each customization to the edition it needs, and confirm current licensing terms and any fees with Filigran.
LTS subscription licensing
If you choose the LTS line, each LTS release requires a specific LTS license key, even though the release is distributed as a container image. LTS releases arrive every 6 months and each is supported for one year, so plan re-licensing and upgrades within that cycle. After a one-month stabilization period, only critical bug and security fixes are released. Ask Filigran how keys are issued and renewed.
Worker infrastructure for connectors
Connectors run as Python workers that consume RabbitMQ messages, so each custom connector adds compute, memory and queue load alongside the platform, Elasticsearch or OpenSearch, Redis and S3-compatible storage. OpenCTI's deployment guidance recommends at least one platform node for every three workers. Check worker counts against feed volume, and include the hosting cost of test and staging environments where upgrades are validated.
Analyst and engineer review time
Someone must review data from custom connectors, confirm that mappings to the STIX2 schema still hold, and check that dashboards, workspaces and playbooks behave after each change. This effort recurs for as long as feeds and workflows run. Ask any partner to define the review cadence and sign-off roles in writing, and decide which of these tasks your own analysts will absorb.
What your team must provide before OpenCTI customization starts
Customization goes faster and costs less when your team has settled a short list of inputs before the delivery team starts. The most important is a running or planned OpenCTI environment that the delivery team can reach with accounts that match the work: platform administrator access for configuration, and a non-production instance where custom connectors, playbooks and dashboards can be built and tested without touching live intelligence. Confirm who issues these accounts, how access is granted and removed, and whether the team may use a shared bastion or VPN into your network. Sample data from each source is the next input. For every feed, MISP instance, spreadsheet or other source you plan to connect, provide representative exports in a non-production copy. Samples should cover normal records, malformed records and the edge cases your analysts already know about. Where samples contain personal data, customer details or material marked under your handling policy, decide whether they are masked, reduced or replaced with synthetic records before they leave your controlled environment. Ask the delivery team to state in writing how sample data will be stored, who can read it and when it is deleted.
Each workflow you want customized needs a named analyst owner. This person decides what a playbook should do, which fields an analyst needs on an entity, and what a dashboard must answer. They also review test results against real casework. Without a named owner, requirements arrive as opinions from several people and changes stall during testing. Plan for that owner to give time during design and acceptance, and record the decisions they make so later changes can be traced. Before build starts, settle the organizations and access groups that the platform will use. Customizations such as playbook scope, entity settings and dashboards inherit the segregation model you choose, so changes to organizations after build can mean rework. Where you plan to use authentication strategies, SSO or organization-based data segregation, confirm which of these depend on the Enterprise Edition, as noted in the sibling topics. Also choose the release line you will run, continuous or LTS, and confirm that you hold a valid license key where the chosen line requires one. Customization must be built against that line, so a late change of line usually means retesting. Finally, name an internal owner who accepts the code after handover. This person signs off the custom connectors, playbooks, configuration and documentation, and becomes the contact for operating them after the engagement ends. They should understand where the code is stored, how it is versioned and how it is deployed to each environment. If that owner is not yet in post, agree who acts in the role during delivery and when the handover will happen. Confirm all of these items with the delivery team in writing before work starts, so the scope and the responsibilities are clear from the first day.
Questions buyers ask about OpenCTI customization
Can our own team customize OpenCTI without outside help?
Yes, many teams do, provided they have engineers who can work with the platform's GraphQL API, the STIX2-based knowledge schema and the connector framework. Simple changes such as adjusting entity settings, building dashboards and workspaces, or configuring existing connectors usually sit well within an in-house team's reach. Work that touches the data model, writes new connectors, or depends on Enterprise Edition features needs more specialist time. Before deciding, list each customization, check which parts need Enterprise Edition licensing, and estimate who will maintain the result through upgrades. Your team's answers to those three points will show whether self-delivery is realistic for your scope.
What drives the cost and timeline of OpenCTI customization?
The main drivers are the number of customizations, how far each one reaches into the data model, access design and connector behavior, and how many systems must be tested after each change. A dashboard or entity setting is a small item, while a custom connector that writes to shared data needs design, development, worker capacity planning and testing against real feeds. Enterprise Edition features, such as playbooks or organization-based data segregation, add licensing and configuration steps. Cost is largely people time, so ask any partner for a written scope that lists each item, its assumptions, its test plan and the environments it covers. Fixed-scope agreements make those trade-offs visible before work starts.
Do custom connectors break when OpenCTI is upgraded?
They can, which is why upgrade testing belongs in the customization plan. OpenCTI uses date-based version numbers and ships non-LTS releases from daily to weekly, so a connector written against one release may depend on API behavior or message formats that change later. Connectors that rely only on documented interfaces and keep their dependencies pinned are easier to carry forward. Plan a staging environment that mirrors production data volumes, run each connector against it after every upgrade, and keep a rollback path. Confirm with the vendor which interfaces are considered stable for your version, and document the connector's dependencies so the next engineer can repeat the test.
Do OpenCTI playbooks require the Enterprise Edition license?
Yes. According to OpenCTI's Enterprise Edition documentation, playbooks are one of the features included in the Enterprise Edition, which is licensed under the proprietary OpenCTI Enterprise Edition License. The Community Edition is licensed under Apache License 2.0 and does not include this feature set. Before scoping work that depends on playbooks, confirm the current feature list and license terms with Filigran or your licensing contact, because the set of Enterprise features can change between releases. Your customization scope should also state which licensed features each item relies on, so the licensing cost appears in the quote rather than surfacing later.
What does customization require from our team?
At minimum, you need a named owner who can make decisions about analyst workflows, data access and naming conventions, plus an engineer who can operate the platform and its dependencies. Customization also needs a test environment, access to representative threat intelligence data, and time from analysts who will validate dashboards, entity settings and playbook outcomes. Depending on scope, you may also need someone to manage secrets for API tokens, network rules for the dependencies, and change approval for production. Ask any delivery partner which of these roles they expect you to fill, and agree who maintains each deliverable after handover.
Should we build OpenCTI customizations in-house or hire a partner?
Choose in-house delivery when you have the skills, a stable team and time to maintain the work through upgrades. Choose a partner when the scope is large, the timeline is fixed, the work spans the data model, connectors and access design, or your team needs to build the skills while the work is delivered. Compare both options on the same written scope, covering deliverables, assumptions, test coverage, documentation, handover and any ongoing support. Ongoing support and upgrade retainers are available from DeployOpen, and most engagements are fixed-scope, so the agreed scope and deliverables are set in writing before work starts. Ask each option how it will handle the next LTS or regular release.
How do OpenCTI release cadence and LTS support affect customization planning?
They set the maintenance rhythm your customizations must follow. Regular OpenCTI releases use the version pattern x.YYMMDD.z and ship when ready, from daily to weekly. LTS releases arrive every 6 months, each supported for 1 year, which gives a 6-month overlap between consecutive LTS versions, according to OpenCTI's product life cycle documentation. LTS releases require a specific LTS license key and receive only critical bug and security fixes after a one-month stabilization period. Decide early whether you will track regular releases or stay on an LTS line, and build the upgrade test cycle around that choice. Confirm the current license terms with Filigran before committing.
How DeployOpen scopes, builds and hands over OpenCTI customization
DeployOpen plans, builds, documents and supports OpenCTI customization inside your own infrastructure, whether that is your cloud account, data center or air-gapped network. Each engagement starts from a written, fixed scope so your analysts, platform team and any licensed Enterprise Edition features are clear before work begins.
How we scope
- We confirm which analyst workflows need custom connectors, playbooks, entity settings or dashboards before agreeing any build work.
- We record which customizations depend on Enterprise Edition features such as playbooks or SSO, so licensing is settled up front.
- We agree the written scope, deliverables and timeline with you before work starts, since most engagements are fixed-scope.
How we build
- We build each customization against your current OpenCTI version and check it against the release line you have chosen.
- We test custom connectors and playbooks against representative data, including STIX2 objects and MITRE ATT&CK content, in a non-production instance first.
- We keep customizations isolated and version-controlled so later platform releases can be tested and applied without rework.
How we hand over
- We deliver written documentation covering each custom connector, playbook, entity setting, dashboard and workspace you received.
- We walk your administrators and analysts through how to change, disable or extend each customization safely.
- We provide a record of what was tested, which releases it was verified against, and the known limits your team needs to watch.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for customizations that must keep pace with releases.
- We can retest customizations when you move between continuous releases and the LTS line, so connectors and workflows keep working.
- Support scope, response expectations and retest cadence are written into the retainer, and you should confirm them before signing.
