Frequently Asked Questions

Governed AI software delivery is AI-assisted software work in which your team writes the tickets, agents return tested pull requests, your reviewers approve every merge, your policy decides model access, and the evidence stays in your own tools. Reign delivers it as a managed service: Reign Factory ships the backlog, Reign Gateway governs model calls, and Reign Ops runs your engineering platforms, operated for you. The full definition is at itmethods.com/learn/governed-ai-software-delivery.

Reign is the iTmethods product line for building and operating AI work inside regulated environments. It is three products available today, and Reign Assurance in co-design development. Reign Factory: tickets in, pull requests out. Reign Gateway: one governed path to the models your teams use. Reign Ops: the platforms you deliver on, operated for you.

Reign Factory is the Build product of Reign: tickets in, pull requests out. It is available today, like Reign Gateway and Reign Ops. It provides implementation and test capacity for well-specified work, opened as a pull request in your review process. Your reviewers approve every merge.

Reign Gateway is the Govern product of Reign: one governed path to the models your teams use. It is available today, like Reign Factory and Reign Ops. It puts identity, policy and spend limits on every call sent through it, and keeps a record in storage you own. Policy is applied before a model or tool call crosses the boundary, and the record covers the request, the decision, the model and version, the destination, the response and the initiating identity. Refusals are recorded too. Agents never hold the keys. Its coverage is the set of routes configured to pass through the Gateway.

Reign Ops is the Operate product of Reign: the platforms you deliver on, operated for you. Available today. iTmethods runs the delivery toolchain for regulated enterprises, including source control, build, artifact management and code quality, as one managed environment with change control, access control and a recorded history of who did what and when. Deployment is a single-tenant dedicated instance. Governance of model access sits in a separate product, Reign Gateway, and defined engineering work is delivered by Reign Factory. Reign Ops is an operating service, not a compliance outcome. Whether your obligations are met is a determination for your own risk and quality functions.

Yes, and each one stands on its own. Reign Factory builds, Reign Gateway governs what crosses to a model, and Reign Ops operates the delivery platform. Where more than one product is in place the records line up: the Gateway records the model boundary crossing, Ops records the change and the approval, and one population of work can be followed from request to merge. Adopting one product does not commit you to another, and no product is available because another one is.

Reign Assurance is in co-design development. It is the Continuous Agentic Assurance motion of Reign: it connects requirements to checks, results and evidence for AI-enabled work. Reign Factory, Reign Gateway and Reign Ops are available today, and each keeps the record behind the work it governs. Reign records support your risk, compliance and audit experts. iTmethods does not issue an audit opinion or a certification.

Yes. The products stand up separately and Reign Gateway does not require Reign Ops. Gateway governs what crosses to a model. Ops operates the delivery platform the work runs on. A customer who wants only the model boundary governed takes Gateway. A customer who wants their delivery tooling operated takes Ops. Where a customer runs both, the Gateway record and the change record from Ops describe the same work from two directions, which is more useful to a reviewer than either alone. Reign Factory is the third product, and neither of the other two requires it.

iTmethods builds and runs Reign, governed AI software delivery for regulated enterprises: Reign Factory ships the backlog, Reign Gateway governs model calls, and Reign Ops runs your engineering platforms. Reign has three products available today, and Reign Assurance in co-design development. We do not publish tiers or pricing on this page. Scope and commercial terms are agreed per engagement in writing and covered by non-disclosure.

Model access runs through Reign Gateway. It supports the major commercial providers, including OpenAI, Anthropic, Google, Amazon Bedrock and Azure OpenAI, and it supports models you host yourself. The list is not the point. The point is that whichever model is called, the call is subject to policy before it is made and leaves a record afterwards covering the model and version invoked, the destination, the response and the identity that initiated it. Which models are enabled for your instance is set by your policy, not by us.

No. Reign Gateway is model-neutral by design. Which providers and which model versions may be reached is policy configuration for your instance, set by you, so a model can be added, replaced or withdrawn without the governing layer changing. Policy enforcement and the record of what was requested and returned happen at the boundary regardless of which model is invoked, which means your evidence trail does not restart when you change provider. That is structural rather than a configuration toggle.

Reign Gateway decides, at the model boundary, whether a request may cross. Policy covers which models and versions may be reached, for which classes of work, carrying which categories of context, under which identity. Policy is configuration set for your instance by your people, not a default inherited from a shared template. A request that falls outside policy is refused at the boundary, and the refusal is recorded with the same detail as an allowed call, because a refusal that leaves no trace is not a control. We describe this as enforcement with evidence. We do not describe it as a guarantee that no mistake is possible.

Reign Gateway records every crossing it handles, including the model and version invoked and the identity behind it, so spend on the governed routes can be attributed to a team, a system or a person rather than arriving as a single line on a provider invoice. Attribution is the part we do. Deciding what to do about it is yours. We do not publish figures for what a customer will find or save, because the only honest number is the one your own traffic produces, and you will have it once the Gateway is running.

Reign Gateway governs the routes that pass through it. It does not block the ones that do not, and we will not say otherwise. Authorized traffic is routed through the Gateway, where policy is applied at the model boundary and every crossing is recorded, including the refusals. Stopping traffic leaving by another path is work your existing controls do, usually network policy at the egress point or endpoint configuration, and it belongs to your security team rather than to us. What the Gateway gives that team is a tested record of what was requested and returned on the governed routes, which is the material you need in order to argue about the ungoverned ones.

Data loss prevention asks what left the building. Reign Gateway asks a different question at a different point: may this request cross to this model, under this identity, carrying this context, and what is the record if it does. The decision is taken in the operational path before the call is made, and the refusal is recorded with the same detail as the permission. Data loss prevention is a control on data movement. The Gateway is a control on agent action. Most organizations that need one need the other as well, and we do not position the Gateway as a replacement for controls your security team already operates.

Reign produces evidence. It does not produce a compliance determination, and no supplier can. Reign Gateway records each crossing to a model: the request, the policy decision applied, the model and version invoked, the destination, the response and the identity that initiated it. Reign Ops records how the environment changed, by whom, and with whose approval. Whether the result satisfies a given framework is a determination for your risk function and for accredited third parties. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed.

Typical Reign Ops estates include GitLab, GitHub Enterprise, Bitbucket, Jira Software, Jira Service Management, Confluence, Jenkins, JFrog Artifactory, Nexus, SonarQube, Terraform, HashiCorp Vault and Plane. The engagement agreement records the exact tool set. Where a vendor runs a tool in its own cloud edition, Reign Ops integrates and supports it rather than operating it. These names identify tools iTmethods operates; vendor relationships and designations are stated separately.

Yes. Reign Ops operates the Atlassian suite, including Jira Software, Jira Service Management, Confluence and Bitbucket, inside a single-tenant dedicated instance. Where you use Atlassian's own cloud, Atlassian runs it. Reign Ops can integrate it with your identity, access and change process and support it; which Atlassian products are in scope is agreed for each platform. Upgrades, patching and configuration are applied to that instance on an agreed schedule under the change process, rather than to everyone at once. Licensing arrangements are settled in the agreement rather than assumed here. Atlassian is named because we operate it, not as a claim of any partnership tier.

Yes. Reign Ops operates GitHub Enterprise Server inside the single-tenant dedicated instance we run for you, or integrates with a GitHub Enterprise Server deployment you already run. Be precise about where that instance sits. It runs in infrastructure iTmethods operates, or in your own cloud account on AWS or Azure. Both are available today, and Google Cloud is planned for 2027. Which components sit inside which boundary is written into the deployment record for your instance rather than left to a general statement on a website.

Reign Ops operates the pipeline tooling as part of the instance, typically Jenkins, GitLab CI or GitHub Actions runners, with artifact management in JFrog Artifactory or Nexus and code quality scanning in SonarQube. Pipelines run inside the single-tenant instance rather than on shared infrastructure. Pipeline, build and deployment telemetry, including job records, timings and outcomes, is retained so a reviewer can follow what ran, when, and on whose approval. Which of these you run, and how they are wired together, is agreed with you.

Yes. Migration is a normal part of an engagement, and iTmethods has moved enterprises off self-managed Jira, Jenkins, GitHub Enterprise and comparable estates onto tooling we operate. We do not promise zero downtime. What we do is agree the cutover window, the rollback path and the acceptance criteria in writing before anything moves, and record what happened at each step so it can be read back later. Migration is scoped as professional services alongside the operating service, and that scope is written into the agreement.

iTmethods combines the software with operation of a single-tenant regulated-production environment. iTmethods has operated regulated-enterprise infrastructure since 2005, and the operating record covers changes, approvals and model or tool calls. Your compliance experts make the compliance decisions.

We do not compete on foundation models and we do not describe other companies' service offerings. Reign is model independent by construction. Reign Gateway routes inference across OpenAI, Anthropic, Google, Amazon Bedrock, Azure OpenAI and models you host yourself, with policy enforcement, logging and evidence produced at the gateway regardless of which model is invoked. Replace the model provider and the governance layer does not change. The rest of what we do is operating regulated production environments, which iTmethods has done since 2005. If you are comparing us with a model provider's own deployment services, put the same question to both: who is accountable for the runtime after go live, and what evidence does the layer produce.

No. Life-sciences organizations use the same three products: Reign Factory, Reign Gateway and Reign Ops. Reign is not a scientific application. What is specific to life sciences is what the record has to survive. Change to a system in scope for GxP is captured as it happens, with named reviewers and named approvers, in a form a validation process can read afterwards. iTmethods holds no life-sciences certification or accreditation and claims none.

A Reign Ops instance is single-tenant and can run in infrastructure iTmethods operates, in your AWS or Azure account, as an air-gapped deployment, or under sovereign deployment requirements. Each instance has its own application tier, database and workload plane. Google Cloud is planned for 2027. Every Reign Ops instance iTmethods operates is single-tenant, now and on the roadmap. Where you use a tool vendor's own cloud service, the vendor runs it and Reign Ops integrates it with your identity, access and change process and supports it.

Yes, on AWS or Azure. Deployment into your own cloud account is available today, and the instance is still single-tenant: provisioned for one customer and serving that customer only. The account and the billing relationship with the cloud provider are yours, and which model applies is written into the deployment record. Google Cloud is planned for 2027. If Google Cloud is a hard requirement, say so early and we will tell you exactly where that work stands.

Reign Ops runs as a single-tenant dedicated instance operated by iTmethods. It runs either in infrastructure iTmethods operates or in the customer's own cloud account on AWS or Azure, and both are available today. Each customer gets their own instance: there is no pooled application tier, no pooled database and no shared workload plane between customers. The cloud provider and region for an instance are agreed at the start of the engagement, and Google Cloud is planned for 2027. Air-gapped and sovereign deployment are supported. A tool a vendor runs in its own cloud is not part of the instance: the vendor runs that service, and Reign Ops integrates and supports it.

Reign Gateway applies the policy set for your instance before a request crosses to a model and records each permission or refusal. Reign runs as a single-tenant dedicated instance in infrastructure iTmethods operates, in your AWS or Azure account, or through supported air-gapped and sovereign deployment. The deployment record states which systems and data sit inside each boundary.

Data is encrypted at rest and in transit. The instance is single-tenant and network isolated, with no pooled application tier, no pooled database and no shared workload plane between customers. Access is role-based, privileged access is named and reviewed, and joiner and leaver handling is documented. Change reaches an instance as a pull request with named approvers on both sides, and the pull request is the record. Vulnerability scanning, monitoring and incident handling are described in the standard pack, including how and by whom you are notified. Platform hardening is designed against published benchmarks, which is a statement about design and not a certification. A dedicated instance is a boundary we operate and record. It is not a guarantee about risk, and we will not describe it as one. Write to security@itmethods.com for the pack.

Reign Ops holds a SOC 2 Type II attestation. The report is available under non-disclosure. Reign Factory and Reign Gateway run on the same infrastructure, team and processes, and the SOC 2 Type II scope is being updated to include them. Write to security@itmethods.com, saying which entity is asking and which regulator or internal standard is driving the question. Holding an attestation is a statement about iTmethods. It is not a statement that your use of the platform meets your obligations.

HIPAA compliance is not something a platform holds on your behalf. It is a determination about your organization and your use of a system, made by your own privacy and compliance functions. What we do is design controls against the published expectations and record what actually happened, so that determination rests on evidence rather than on assertion. The categories of data in scope for an engagement, including any protected health information, are agreed and written into the agreement before work begins, together with what contractual instruments that requires. Alignment is not compliance, and we will not describe it as compliance.

There is no such thing as an FDA-compliant platform. 21 CFR Part 11 sets expectations for electronic records and electronic signatures, and whether a computerized system in your estate meets them is decided by your quality function, not by a supplier. What Reign does is capture the record those expectations rest on. Who made a change, who reviewed it, who approved it and when, recorded as the work happens rather than reconstructed afterwards. Where a model took part in a change, the record says so. Reign stops there. It does not perform validation and does not decide whether a system is validated. Reign prepares; people decide. iTmethods holds no certification, accreditation or approval under 21 CFR Part 11 and claims none. Alignment is not compliance.

GxP is not a status a supplier holds. It is a set of expectations your organization answers to, and whether a system in scope meets them is decided by your quality function and by accredited third parties. Reign contributes in one specific way. It records change to the delivery estate as it happens, with named reviewers and named approvers, and it records model calls together with the policy that applied to them. That record is what a validation process reads. Reign does not perform validation, does not certify, does not attest and does not issue an audit opinion, in any tense. iTmethods holds no GxP-related certification or accreditation and claims none.

Patient data is a category that has to be named before it is handled, not assumed. The categories of patient, trial and personal data in scope for an engagement are agreed and written into the agreement before work begins. Inside the instance, data is encrypted at rest and in transit, access is role-based, privileged access is named and reviewed, and access is recorded. Where a model is called, what may cross the boundary is set by policy before the call and recorded by Reign Gateway afterwards. If your policy enables a commercial model provider, calls to it leave your instance, and the record says so. If that is not acceptable for a given category of data, the policy is where you say so, and it is enforced at the boundary rather than by convention. iTmethods makes no claim to hold HIPAA compliance. Whether an engagement meets your obligations is a determination for your privacy function.

Yes. Reign Gateway governs access to commercial models and to models you host yourself, including models you have trained or fine-tuned. Which models are enabled is set by your policy. Whichever is called, the call is subject to policy before it is made and leaves a record afterwards covering the model and version invoked, the destination, the response and the identity that initiated it. Hosting a model yourself changes where the call goes. It does not remove the need for the record, and it does not by itself answer a sovereignty requirement; deployment of the instance is the part that does, and that is a single-tenant dedicated instance today.

Yes. Reign Ops supports enterprise single sign-on through SAML 2.0 and OIDC, and integrates with identity providers that implement those standards, including Okta, Microsoft Entra ID, Ping Identity and OneLogin. Identity configuration, credentials and access rules are specific to your instance and are not inherited from a shared default that other customers also carry. Your provider and the exact configuration are confirmed during scoping and recorded in the deployment record for your instance.

Each Reign Ops instance runs in its own virtual private network, with private subnets and controlled ingress. Traffic in transit is encrypted with TLS. Web application firewalling, provider-level denial-of-service protection and private endpoints are configured for the instance. Private connectivity into your network, by VPN or a dedicated circuit, is arranged per engagement. The network design for your instance is documented for that instance.

Reign Ops runs as a single-tenant dedicated instance. Resilience is designed for the instance: redundancy, failover arrangement, backup and recovery are set for that instance and written into its engagement documentation, because they depend on the region and the workloads involved. Instances are monitored and incidents are handled by the iTmethods operations team. Service levels and support scope are set out in your contract and provided under non-disclosure. For a tool a vendor runs in its own cloud, the vendor runs the service; Reign Ops supports it.

Backups of a Reign Ops instance are automated, encrypted, and stored separately from the running instance. Retention periods, recovery point and recovery time objectives, and restore testing are agreed per engagement and documented for that instance rather than fixed by a published figure. Restore procedures are run by the iTmethods operations team.

iTmethods manages upgrades and security patches for a Reign Ops instance as part of the service. Patches are prioritized by severity, and the target window for each severity level is agreed per engagement rather than published here. Feature upgrades are tested before rollout, and changes that alter existing behavior are notified in advance. Maintenance windows are agreed with you.

HashiCorp Vault is part of the managed tool set in a Reign Ops instance, with secrets encrypted at rest and access controlled by role. Rotation policy is configured for your instance. Where you already run AWS Secrets Manager or Azure Key Vault, the instance is configured to use it rather than duplicating it. Which secrets rotate automatically depends on the systems that hold them, and that mapping is documented for your instance.

A Reign Ops instance produces centralized application, platform and access logs, with metrics dashboards and alerting. Logs can be exported to your own SIEM, including Splunk and Datadog. Access to the instance is logged with user attribution. Which sources are collected, and how long they are held, are set for your instance and documented there. Logs are an input to your compliance work. They do not by themselves make an organization compliant.

[Book a briefing](/briefing) and bring the workloads, environments and regulatory obligations involved, or write to reign@itmethods.com. The team will confirm the relevant Reign product, scope and next step.

That depends on your environment, and we do not publish a number on this page rather than invent one. Reign runs as a single-tenant dedicated instance provisioned for one customer. What sets the timeline is your identity configuration, your network boundary, the repositories and systems in scope, and the reviewers who own them. We scope it with you under non-disclosure and tell you what it will take once we have seen the environment. If the honest answer at that point is longer than you wanted, that is the answer you will get.

No. There is no free trial and no self-service signup. Reign Ops is a single-tenant dedicated instance built to your requirements, so an evaluation is a scoped engagement with a written statement of work rather than a button. We do not publish an evaluation length, because the length is set by what is being evaluated.

Commercial terms for Reign Ops are set per engagement from the workloads, environments, operating scope and regulatory obligations involved. The agreed terms appear in the written proposal and contract. [Book a briefing](/briefing), or write to reign@itmethods.com.

Reign Factory is bought as one subscription per delivery process. The subscription includes a supervisor with five AI workers, operation 24×7 and engineer hours, and you add workers in packs of five as the work grows. We do not publish prices on this page. [How you buy Reign Factory](/factory#buy) sets out the unit.

We do not publish pricing or a pricing model for Reign Gateway on this page. Reign Gateway is the Govern product. Pricing is agreed in writing and covered by non-disclosure. Reign Factory, Reign Gateway and Reign Ops are contracted together or separately depending on what is in scope.

Term length, billing frequency and payment terms are agreed per engagement and recorded in the contract. We do not publish payment terms or discount structures on this page rather than advertise terms that get renegotiated in every deal. Procurement questions go to reign@itmethods.com.

Term length is agreed per engagement. Regulated deployments are usually annual or multi-year because the instance is dedicated and built to the customer's requirements, but we do not publish a term ladder or the commercial treatment attached to one. Term, renewal and notice provisions are written into the contract.

Termination rights are whatever your contract says they are, including notice periods and any early-termination provisions. We do not publish termination terms on this page, because they are negotiated per engagement. If your requirements change, raise it with your account team and we work the contract rather than around it.

Reign Ops is a single-tenant dedicated instance that iTmethods operates: the toolchain agreed in your scope, platform operations, patching and upgrades, and the evidence the platform produces while it runs. What is in scope, what is out of scope, and the service levels attached to it are set out in your contract and reviewed quarterly. Where a tool vendor runs a tool in its own cloud, Reign Ops integrates and supports it rather than operating it. We do not publish a tool count or a package price, because scope is set per engagement.

Yes. Where you use a tool vendor's own cloud service for a tool, Reign Ops integrates it with your identity, access and change process and supports it. The vendor runs that service; Reign Ops does not. The tools covered are agreed for each platform, and what support includes is set out in your agreement. Every Reign Ops instance iTmethods operates remains single-tenant.

Yes. iTmethods provides migration, integration, training, architecture review and compliance-evidence work alongside the platform. These are priced in the statement of work. We do not publish rates on this page rather than quote a number that moves with scope and seniority.

Administrator training, engineering enablement, and evidence and audit walkthroughs are available, delivered remotely or on site. What is included and what is charged separately is set out in your statement of work rather than by a standard tier.

We do not publish service level numbers on this page. A target quoted without knowing the scope it covers is marketing rather than a commitment. Service levels are agreed per engagement and written into the agreement. Targets, incident handling and remediation are provided on request under non-disclosure. Existing customers keep the levels they have already agreed. Those stand exactly as written and are not restated, reinterpreted or replaced by a change of name.

Support is provided by named people under the terms of your agreement, and escalation runs to the engineers who operate your instance rather than into a queue. For a tool a vendor runs in its own cloud, the vendor runs the service and Reign Ops supports it; what support includes is set out in your agreement. We do not publish support tiers or response time guarantees on this page. What is committed is what is written into your agreement, and that is where to look. Existing customers keep the support address, ticket path, escalation ladder and people they use today. None of it changed with the name.

Reign is built for organizations where somebody has to answer for an action after it has been taken: banking, capital markets, life sciences, semiconductor and defense, operating under customer or regulatory obligation. The common feature is not the sector. It is that AI work touches something a reviewer will later ask about, and that a summary written afterwards by the people who did the work is not sufficient. Reign is designed against published regulatory expectations and maps its controls to them. That is alignment, not compliance. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed, and the compliance determination stays with your risk function.

Reign serves life-sciences organizations of different sizes. The fit depends on the systems and data in scope and the controlled record their quality process requires. Book a briefing and bring those systems and data categories.

iTmethods works with public sector organizations and can work through prime contractors and established procurement routes. Reign Ops holds a SOC 2 Type II attestation. The report is available under non-disclosure. Reign Factory and Reign Gateway run on the same infrastructure, team and processes, and the SOC 2 Type II scope is being updated to include them. Where a program requires an authorization we do not hold, we say so before the paperwork starts.

iTmethods works with advisory, technology and referral partners, and each arrangement is agreed in writing. Start from the [Partners page](/partners), or write to reign@itmethods.com and say what you build or operate and the institutions you already serve.

iTmethods was founded in 2005 and has spent two decades running enterprise DevOps and platform infrastructure for regulated organizations, under the same founder and the same legal entity. Customer references are provided on request under non-disclosure.

Paul Goldman is the Founder and Chief Executive Officer of iTmethods, and the company remains founder-led. The leadership team is listed on the [Leadership page](/company/leadership).

See [Status](/status) for product status, [Deployment](/deployment) for deployment models, and [Security](/security) for security, subprocessors and the procurement pack. To discuss your environment and control requirements, [book a briefing](/briefing) or write to reign@itmethods.com.

Reign Ops is iTmethodsONE under a new name. Same platform, same team, same agreements. iTmethodsONE means Reign Ops, and Reign Ops is the only current name. Your existing tools, configurations, workflows, service levels, support routes and invoices are unchanged, and nothing is being added to your service because a name changed. Governance of model access is a separate product, Reign Gateway. If you changed nothing at all after reading this, you would be doing the right thing.

No. A rename does not change what you have contracted for. Your contract remains in force on its existing terms with iTmethods Inc., and the service you are running is the same service under a new name. Anything that would change scope, commercial terms or service levels happens through the contract and is agreed in writing. It does not happen through a rebrand. Production SLAs are set out in your contract and reviewed quarterly.

So that what we build and run carries one name. Reign brings three related products under it: Reign Factory, Reign Gateway and Reign Ops. iTmethods Inc. remains the contracting entity, and the same team runs your existing service to the same levels, under the same agreements.

No. iTmethods Inc. remains an independent, founder-led company. Paul Goldman remains Founder and Chief Executive Officer. There is no change of ownership, control, or contracting entity. The rebrand changes the name of the platform and nothing about who you are contracted with.

iTmethods Inc. is the legal entity, and the rebrand does not change it. Reign is the platform brand that iTmethods Inc. builds and operates. Contracts, invoices, attestations and legal relationships continue to sit with iTmethods Inc. No novation, no assignment and no new counterparty is involved in a change of product name.

Call the company iTmethods, cased exactly so. Call the platform Reign. Name the product when it matters: Reign Factory for Build, Reign Gateway for Govern and Reign Ops for Operate. iTmethodsONE is the retired name for Reign Ops and should not be used as a current product name.

No. Your existing contract remains valid, because the counterparty has not changed. iTmethods Inc. is still the contracting entity. If a naming reference needs to be updated for your own records, that is handled as a written amendment at renewal. Nothing about the rename requires you to reopen commercial terms.

No. The rebrand does not change any commercial term. Your pricing is set by your contract and can only change in the way your contract says it changes. We do not publish pricing on this page, and a change of name is not a change of price.

No action is required. The rename does not invalidate a purchase order, a vendor record or a signed agreement, because the contracting entity, iTmethods Inc., has not changed. When you next update vendor records in the ordinary course, the company is iTmethods, the platform is Reign, and the product you operate is Reign Ops.

That is not a problem. Older names such as iTmethodsONE refer to the same platform and the same service under the same contract. Nothing in your environment depends on which name your team uses. We use Reign Ops in current documentation so that there is one current name.

Invoices continue to come from iTmethods Inc., and payment terms are set by your contract rather than by the product name printed on the invoice. If the descriptor on an invoice changes to match the current product name, the amount, the terms and the counterparty do not change with it.

The rebrand does not reassign accounts. Named contacts and support arrangements are set by your contract and are not altered by a change of product name. If your account contacts change for an ordinary business reason, we tell you directly rather than through a rebrand.

Use this. iTmethods has renamed its platform to Reign. The product we operate is Reign Ops. The contracting entity, iTmethods Inc., is unchanged, so our agreement, our purchase order and our vendor record stand as signed. Any change to scope or commercial terms would reach us in writing through the contract, not through a change of name.

No. The rebrand does not change the entity that holds attestations or the programs behind them. Reign Ops holds a SOC 2 Type II attestation. The report is available under non-disclosure. Reign Factory and Reign Gateway run on the same infrastructure, team and processes, and the SOC 2 Type II scope is being updated to include them. Reign does not make a customer compliant, certified, validated or qualified. It produces the evidence that a customer's own compliance function uses.

The portal remains at portal.itmethods.com. If we introduce an additional hostname under the Reign name, existing bookmarks and integrations get notice and a migration window before anything changes. We do not promise a URL forever on this page, and we do not change one without telling you first.

Support runs through the ticket path named in your contract, and that path did not change with the name. It remains the fastest way to reach the people who run your platform. Support scope, escalation paths and service levels are set out in your contract and reviewed quarterly. We do not publish response times on this page rather than publish a number your contract does not owe you.