Documentation

How the platform works

Every surface in geneworks.ai follows the same shape. Learn it once and the whole platform becomes predictable. The only variable is which part of the estate a given surface points at.

Reading is always separate from writing. Assessment surfaces cannot change your instance, no matter what is asked of them. A write requires three things at once: a user who started it deliberately, a workspace where that user holds the role, and a design that has already cleared its gate.

The three layers you will use

Concepts and vocabulary

Twenty terms carry most of the platform. Everything else is built from them.

Structure

• Organization — your tenant. Every user, workspace, project and record belongs to exactly one organization, and nothing is shared between organizations.
• Environment — the dedicated, single-tenant deployment provisioned for you, holding all of your content. One environment per client instance environment.
• Workspace — a connection to exactly one ServiceNow instance. Credentials, analysis data, run history and artifacts are scoped to it.
• Project — the container for a body of work: its business case, ideas, requirements, backlog, documents and delivery history. It is permanent, and that permanence is what makes context compound.

Work

• Objective — an organizational intent drafted from a leadership mission statement. Projects align to one.
• Sticky — an unstructured idea dropped onto the ideas board. The lowest-friction way into the system.
• Requirement — a need stated in plain language, on behalf of a named stakeholder, that Gene elaborates into structured work.
• Epic — a unit of scope in the backlog. Every epic arrives from Mission, from Requirements, or from the ideas board.
• Story — a sized, testable slice of an epic. Stories and tasks are what appear on the board.
• Action — the executable unit handed from planning to the build engine, carrying its own scope, dependencies, acceptance criteria and test expectations.

Execution and evidence

• Gene — the orchestrator you talk to, and also the name of the reusable unit of encoded intelligence (see Genes). Context makes clear which is meant.
• Scan — a read-only pass that maps, scores or classifies part of your estate. Writes nothing, ever.
• Finding — a scored issue with a recommended fix, exportable into governed work.
• The delivery loop — the seven stages from requirement to deployed change, with a human gate at design and another at evidence review.
• Human gate — a mandatory approval by a named person, recorded against the work. There are two, and neither can be bypassed.
• Impact analysis — a read-only trace of the blast radius of a proposed change across the dependency graph, run before the design gate.
• Update set — the named, scoped ServiceNow package carrying the change, reversible by backout. geneworks.ai never lands changes in Default.
• Evidence package — the immutable record of a verification run: test results, screenshots, video, logs, and the approval that closed it.
• Workspace memory — the accumulated instance-specific and project-specific knowledge that makes later work cheaper than earlier work.
• Honest reporting — the platform states what it actually completed. A partial build is reported as a partial build, with a runbook for the remainder.

Architecture

One isolated environment per customer, outbound-only connectivity, and a control plane that never holds your content.

Everything else in the security model follows from that single organizing principle. geneworks.ai is not conventional multi-tenant software: there is no shared application runtime and no shared database with row-level separation between customers.

Five isolation zones

Inside your environment

Encryption and keys

AES-256 at rest under customer-managed KMS keys, TLS 1.2+ in transit on every external connection. Because the keys are yours, you can render your own data inaccessible without involving geneworks.ai. That converts a checkbox on a security questionnaire into a control you actually hold.

Projects and the workspace

Where business intent is captured, argued about, and turned into work.

Most delivery tooling starts at the point where a requirement is already written down. By then the expensive part has already happened, badly, in meetings and documents nobody will read again. The geneworks.ai workspace starts earlier: a leader describes a direction, anyone drops a rough idea on a board, a stakeholder says what they need in a sentence, and the platform does the structuring.

A project is the container for all of it. It holds its own business case, ideas, requirements, backlog, board, documents and delivery history, and it aligns to an organizational objective so the work can be traced back to why it was funded.

What sits in a project

The intake paths

There are three ways work enters a project, and they exist because people think in different registers. A sponsor thinks in outcomes, a stakeholder thinks in problems, and a practitioner thinks in half-formed ideas at the end of a workshop. All three land in the same backlog.

Mission and objectives

Executives state direction in plain language. The platform turns it into objectives projects can align to.

Mission is the organizational surface, not a project one. A leader writes one or two sentences about what matters this quarter and tags the dimensions it touches: efficiency, compliance, growth, risk, customer. Gene reads it, asks about anything it cannot infer, and drafts a set of objectives.

The point of the surface is traceability in both directions. From an objective you can see every project working toward it. From a story on a board you can walk back to the epic, the requirement or sticky it came from, the project, and the objective that justified it. When someone asks why an engineer spent three weeks on a catalog item, the answer is a chain rather than a recollection.

Ideas board

A wall of sticky notes that becomes a backlog.

The ideas board is unstructured intake, and it is deliberately the least demanding surface in the platform. There is no form, no mandatory field, no template and no correct way to phrase something. Anyone with access to the project drags a sticky anywhere on the canvas and writes what is on their mind. It works the way a whiteboard in a room full of people works, which is the point: the useful part of a workshop is the mess, and most tools make you throw the mess away before it can be captured.

What happens to a sticky

The board is where a workshop stops being an event and starts being an input. Nothing has to be re-typed into a requirements tool afterwards, and the ideas that did not make the cut stay visible instead of evaporating in someone’s notebook.

Requirements intake

Say what is needed, on behalf of whoever needs it.

The requirements surface is for the case where you know who wants something and roughly what it is. Look the person up in the stakeholder directory, describe the need in plain language, and Gene elaborates it into a structured epic in the project backlog.

Two details make this work rather than merely look tidy. First, attribution is mandatory: every requirement is filed on behalf of a named stakeholder from the directory, so there is always someone to go back to when a decision is needed. Second, Gene asks rather than assumes. Where the description leaves a genuine gap, the elaboration says so explicitly instead of inventing a plausible answer and burying it in acceptance criteria.

Stakeholder directory

An organization-wide register of everyone who can be named on a requirement, with role, department and contact. It is shared across every project, so a stakeholder recorded once during one delivery is available to the next one.

Business case

Gene assembles the business case for a project from its name, description and aligned objective, and it can be regenerated whenever scope shifts. It is a working document rather than a one-off artefact produced to unlock funding and then never opened again.

Backlog and board

Epics become sized stories. Stories become Actions.

The backlog holds epics and the stories under them. Whatever route an epic arrived by, it behaves the same way from here.

Generating stories is where estimation stops being a meeting. Gene slices an epic into testable stories, sizes each one, and drops it onto the board. The sizing is a starting position rather than a verdict, and a delivery lead overrides it in the ordinary way.

The board is a sprint board grouped by epic. Only stories and tasks appear on it. An epic with no generated stories stays in the backlog until it is sliced, which keeps the board an accurate picture of committed work rather than a wish list.

Artifacts and documents

Documentation written from the work, not from a blank template.

Artifacts is the documentation surface inside a project. It holds the functional requirements document and the technical design document for the work in that project, and it generates delivery documentation from what was actually built.

The two living documents

The template library

Beyond the two living documents, Artifacts generates delivery documentation from a maintained template library, in DOCX, PDF, PPTX, XLSX and HTML.

Plan

Turn a conversation into Actions. Public product: Software factory — from request to work order.

Plan is where an instance becomes legible and a change becomes a specification. It is the entry point for everything else, because nothing should be built against an estate nobody fully understands. Three surfaces sit under it: Command Center, Application Explorer and Artifacts.

Command Center

Mission control for an instance. Command Center reads the whole environment and renders it as one living, zoomable graph across three layers: applications, connected components such as notifications and reports, and the metadata layer of system metadata, micro components, logs and audit records.

Tracing 8,634 connections to find the 15 that matter is not hand work. The scan is read-only, so the question can be asked before anything is touched.

Application Explorer

An x-ray of a single application. Explorer reads an app end to end and shows how it is built, splitting every artifact into out-of-the-box, customized and net-new, and showing where the customizations concentrate. It is the fastest route to understanding an application you did not build, and the foundation of any upgrade review.

• Composition — baseline against customized against custom. Here, 713 baseline at 96.2%, 28 customized at 3.8%, and nothing net-new: a near-vanilla application that will upgrade cleanly.
• Artifacts by area — data model 220, user interface 117, process and automation 147, security and access 109, reporting 74, business logic 68, intake 6.
• Customization heat map — the upgrade-review view. Security and access 15, process and automation 6, business logic 4, reporting 2, interface 1.

Every application opens as its own workspace with its own agents and its own tabs: Overview, Ask Gene, Plan, Configure, Testing, Troubleshoot and Artifacts. When the instance changes underneath it, Explorer prompts a re-scan rather than quietly serving a stale picture.

Artifacts

The documentation surface, covered in full under Artifacts and documents. It holds the functional requirements and the versioned technical design document, and generates delivery documentation from the work performed.

Build

Turn intent into working software. Public product: SDLC automation — this is the build half.

Build turns an approved design into real ServiceNow configuration. It runs a full product development lifecycle — plan, build, configure, test, document, release — across both out-of-the-box applications and custom scoped applications.

What Build produces

App Builder

The surface for building an application rather than changing an existing one. It carries the same governance: a design a named human approves, dependency-ordered execution, tests authored with the build, and a scoped update set at the end.

Fluent SDK and TypeScript output

Where Flow Designer artifacts are authored as TypeScript through the Fluent SDK (version 4.3 and above), the output is version-controllable, reviewable in an ordinary code review, and diffable across releases. For a practice running many client environments, diffability is what makes it possible to show exactly what differs between them.

Safe, non-destructive deployment

Before writing, the platform merges instance changes made since the last deploy, so it never silently overwrites someone else’s work. Every step is checkpointed and reversible, and a partial completion is reported as a partial completion.

Verify

Prove every change. Public product: SDLC automation — this is the evidence half.

Verify tests each change two ways and captures the evidence as it runs. geneworks.ai owns the runner for both, so test execution does not depend on additional ServiceNow licensing.

ATF Test Center

ServiceNow’s Automated Test Framework, server and client suites, authored alongside the build and executed on the GeneWorks Cloud Runner. Tests are stored in your instance and you own them. No ServiceNow CloudRunner license is required, which removes a direct line item that would otherwise be a prerequisite for automated testing at this scale.

Validation Center

Functional and user acceptance testing driven through a real browser. An agent logs in with the service account, navigates to the relevant form, fills the mandatory fields, exercises the journey and captures screenshot and video evidence at every step. This is the actual user path, not an assertion about it.

Self-healing tests

Routine interface change breaks automated tests, and maintaining a large regression estate by hand is what usually kills test automation in year two. Self-healing absorbs known-pattern failures and re-runs, through one-click Fix ATF and Fix FT. What it cannot repair is flagged for a human rather than retried blindly or quietly dropped.

Evidence and audit store

Every verification run is written immutably against the work that produced it: results, screenshots, video, logs, and the identity of the person who approved it. Built for SOX-type control environments, where the question is not whether the change worked but whether you can demonstrate it worked, on whose authority, at what time.

Process Analyst

Analysis of how a process actually runs against how it was designed to run, across the catalog and across the platform generally. It produces findings, and findings route into governed work like any other.

Optimize

Continuously improve what you already have. Public product: Organizational Memory — filed, so the next pass starts here.

Optimize scores the parts of the platform that degrade quietly: CMDB health, catalog quality, reference data and upgrade readiness. Every finding it produces can become governed work. Five surfaces, one pattern.

CMDB Rapid Assessment

Connect an instance, run a scan, and get a full maturity assessment without a consultant-led discovery workshop. Four tabs: Executive Readout, CSDM Practices, Findings and Roadmap, and Scan History. Every figure in the readout drills through to how it was measured.

• Completeness — mandatory and recommended attributes scored separately, and discoverable separated from non-discoverable. A missing mandatory field is a broken process; a missing recommended field is unrealized value. They should not share a number.
• Correctness — stale CIs not refreshed inside the window, orphan CIs with no relationships, and duplicates found by class-aware identification rather than name matching.
• Compliance — reported only where it can be measured read-only. Where it cannot, it is flagged as requiring an audit job rather than scored as zero.

An assessment that conventionally takes four to five weeks of consulting time completes in under an hour, and every finding on the roadmap can be handed to Gene as workable tickets.

Catalog Center

Every catalog item scored 0–100 across four equally weighted pillars, with bands at 85+ Excellent, 70–84 Good, 50–69 Needs Attention and below 50 Critical. Two views: a builder-facing fix-it queue and a leadership-facing portfolio rollup.

Every fix carries two actions: ask Gene to explain it, or propose it as a change. New catalog items can also be authored, and existing ones updated, from inside Catalog Center.

Upgrade Assist

Tells you what will break before you upgrade. Pick a target release; the platform detects your current version and patch level, pins the release knowledge for that target at kickoff, and cross-references every documented change between the two against your live instance, read-only. Release documentation for a single upgrade routinely runs past two thousand pages. Coverage spans 900+ plugins, 200+ applications and 300+ tables.

Blockers surface first and group by application, so remediation is scoped before the upgrade window opens. Fix with Gene routes a finding into the delivery loop and deploys it; a re-scan then verifies closure rather than assuming it. Re-verify re-reads only the items that could not be verified and leaves settled classifications untouched. Upgrade Assist also reads the upgrade history log, so customizations skipped on a previous upgrade do not silently re-break on the next one.

Normalize

External normalization for CMDB and SAM across four table domains: companies and vendors, software installs, locations and departments. It runs against geneworks.ai’ own publisher and product database, refreshed nightly. There is no third-party normalization data subscription and no SAM Pro dependency.

High-confidence matches auto-accept and the rest enter a review queue where each variant is accepted, rejected or escalated. Accepting a match approves a proposal: your instance data changes only when the accepted candidates are applied. Matching rules, the canonical catalog, record lifecycle and a replayable run history all stay under your control.

Tech Debt Assessment

The executive layer over everything above: a debt index, annual maintenance cost exposure, upgrade readiness as a percentage, modeled savings, an ROI waterfall and a remediation roadmap. It quantifies the cost of the current state rather than describing it, which is the version of the conversation that gets remediation funded.

Ask Gene

Present inside every product, not a product beside them.

Ask Gene is the conversational surface, available across the platform and inside every application workspace. Ask a question about the connected instance, investigate why something broke, interrogate delivery history, or start governed work in plain language. Gene classifies intent and routes to the right specialists.

Ask Gene inherits the governance of every other surface. Read questions answer directly. Anything that would write to your instance becomes proposed work subject to both human gates. There is no path through the conversational interface that avoids them.

The seven stages

Whether work arrives from a sticky note, a stakeholder requirement, or a finding accepted from any assessment surface, it runs the same loop. Each stage produces a discrete, auditable artifact, and two stages are human gates.

How the loop maps to the interface

The shipped product tabs are Overview · 01 Requirement · 02 Design · 03 Task Planner · 04 Execute · 05 SN Deploy · 06 Verify. Stage 4 above is Task Planner plus Execute. Both gates are visible in the interface: Design carries Status: Draft — Awaiting Design Authority Review, and Verify is Verify and sign off.

A change, end to end

Here is a real change, CH-001, auto-prioritize VIP callers, as the task planner decomposed it. Note the dependencies between tasks, and the load-bearing decisions carried through to execution.

The planner does not merely list tasks. It reasons about execution order, edge cases and prerequisites, and it records that reasoning so a human reviewer can check the thinking at the design gate rather than only the output at the end.

The two human gates

Two approvals are non-negotiable, and they are the reason the platform is safe to run at speed.

Honest reporting sits behind both gates. Out of a hundred stories the platform might complete seventy-three and hand back a clean runbook for the remaining twenty-seven. It says so. The gates exist precisely because some work belongs to humans, and a platform that hid the boundary would be more dangerous than one that has none.

Impact and collision analysis

Before any build, the platform scores the blast radius across eight health dimensions. It is the same read-only graph analysis that powers the Collisions lens in Command Center, run automatically and presented to the reviewer before the design gate.

Risk triage. LOW means every dimension sits below threshold and the work proceeds once the design is signed off. MEDIUM means one or more dimensions are elevated and the build pauses mid-execution for review. HIGH means critical risk and the build does not start until the change is rescoped or explicitly authorized.

Dependency awareness compounds. Every completed change records the dependencies it touched, so a later change to a related object surfaces as a blast-radius risk even when the person making it has no idea the connection exists. That is the failure mode manual review is worst at.

Testing and evidence

Every change is tested two ways, and geneworks.ai owns the runner for both. See Verify for the product view; this is how testing sits inside the loop.

• Automated tests are authored at stage 4 alongside the build, executed at stage 5 on the GeneWorks Cloud Runner, and stored in your instance.
• Functional tests run at stage 5 through a real browser, producing the screenshot and video evidence the review gate examines at stage 6.
• Self-healing repairs known-pattern failures and re-runs them. Anything outside a known pattern is flagged for a human rather than retried until it passes.

Update sets and rollback

Every change is delivered as a named, scoped ServiceNow update set: the platform’s own native mechanism for packaging and transporting configuration between environments. Nothing about your promotion path has to change to accommodate geneworks.ai.

Preview and commit. Import the update set into the target environment, preview it, resolve any flagged conflicts, and commit after your own change approval. All changes apply in a single audited transaction.

Rollback. Any update set can be backed out after commit, and the platform preserves before-and-after state for verification.

Specialist agents

Specialist agents, backed by a database rather than by a prompt.

The delivery work is carried out by specialist agents organized into five groups and coordinated by Gene. They are not ephemeral personas assembled at request time. They are persistent, trainable, and the training stays in-house. Their behavior is therefore consistent between one engagement and the next.

A further set of agents maintains the publisher and product reference catalog that Normalize runs against, refreshing it nightly.

The internal skill chain

Every build agent runs the same internal chain of roles, so each one produces a complete tested artifact rather than a fragment somebody else has to finish:

Every agent action is recorded with organization, workspace, user, timestamp, operation and target. Agents reach ServiceNow only through the governed integration layer, as a controlled set of scoped operations. No agent ever holds raw instance credentials.

Genes

The smallest reusable unit of executable enterprise intelligence.

A Gene is a standard, encoded once, that the platform can then execute everywhere. It might be a policy, a delivery pattern, a control, a testing rule, a naming convention, a best practice, or a decision standard. What matters is that it stops being a document somebody is supposed to have read and becomes something the platform enforces while it works.

A standard encoded for one engagement is executable across every later engagement without re-teaching anyone. This is why the platform ships with 500+ ServiceNow skills already encoded, and why an organization’s own conventions become a compounding asset rather than a training burden that resets whenever someone leaves.

Sequencing and orchestration

Deciding what runs, in what order, and what must not run yet.

Gene holds authoritative task state for all work in a workspace. It classifies intent, routes each unit of work to the right specialist, sequences execution, enforces both gates, and synthesizes the outputs back into one coherent result. Nothing runs because an agent decided to; work runs because the orchestrator scheduled it against a plan a human approved.

The practical consequence is that the platform’s throughput is not the speed of one agent. It is the width of the dependency graph. A change that decomposes into fifteen independent artifacts finishes in roughly the time the longest chain takes, not the sum of all fifteen.

GeneWorks LLM

The platform runs its own model harness. The model is a component, not the product.

geneworks.ai does not connect agents to a model and hope. Between the agents and the frontier model sits the geneworks.ai harness, and it is the layer responsible for everything that determines whether an agentic system is dependable in production: what context an agent is given for a piece of work, which tools it is permitted to use, how tool results are validated before they are trusted, how failures are classified, and when a run should stop and ask a human instead of continuing.

Cloud Runner

geneworks.ai built its own test execution runner. That removes a license, and it removes a ceiling.

Executing ServiceNow’s Automated Test Framework through an integration normally requires CloudRunner, a paid ServiceNow product. geneworks.ai built its own runner instead, and the effects go further than the line item it removes.

• No ServiceNow CloudRunner license is required. Automated testing at delivery scale stops being a procurement conversation.
• Both kinds of test run on the same runner. Automated framework suites and browser-driven functional tests execute in one place, so the evidence for a change is assembled from a single run rather than stitched together from two systems.
• Execution scales with the work, not with the instance. Because the runner sits outside ServiceNow, test throughput is not constrained by the instance’s own execution limits, and a large regression estate across many environments stays viable.
• Evidence is captured at source. Screenshots, video and logs are written into the workspace by the runner as the test executes, so the evidence package cannot disagree with what actually happened.

Tests themselves are stored in your instance in the normal way. You own them, you can read them, and they remain valid if the platform is ever removed.

Token optimization

The cost of running agents at delivery scale is an engineering problem, and it was solved as one.

Agentic delivery is expensive by default. A naive implementation spends model capacity re-reading the same context on every step, and the bill grows with the size of the estate rather than with the amount of work delivered. geneworks.ai runs a token optimization engine inside the harness whose job is to keep the cost of a unit of delivered work roughly flat as projects get larger and longer.

Measured against comparable agentic approaches to the same work, the platform runs at approximately one tenth of the token cost.

Memory and learning

The platform gets more reliable the longer it runs on your estate. Three mechanisms drive that, and none of them involves training a model on your content.

The workspace is the context engine

Every change to an application stays in the same workspace permanently. One cockpit per project, holding the full history of what was asked for, what was designed, what was built, what was tested and what was decided. The technical design document versions forward, and each new requirement adds tasks on top of the ones already there rather than starting from an empty page.

This is the real answer to “how does it remember?” The memory is the accumulated project record, held in your own environment, not a separate product bolted on the side.

What changes as a workspace matures

The training corpus

The agents were trained across the ServiceNow ecosystem: product documentation, upgrade and release notes, product fixes and known errors, community material, partner methodologies, support documentation, and geneworks.ai’ own delivery IP. That is why proposals follow documented practice instead of inventing a plausible-looking approach.

Pre-training on real delivery work is the difference against building your own. An organization assembling its own agents starts cold on every engagement. This one does not.

Self-healing and lessons learned

When a build or a test fails on a known pattern, the platform repairs it and re-runs. Every failure is written to a lessons-learned record that agents read before acting, so repeated mistakes on your estate decline over time and fewer failures reach a human at all.

Prerequisites

Onboarding needs five things. No plugin, MID Server, appliance or installation is required.

• The instances in scope. Which ServiceNow instances are connected and in what promotion order, each reachable at https://<instance>.service-now.com. Most engagements start with a sub-production instance.
• An integration identity per instance. A dedicated integration user, never a personal account, with OAuth 2.0 client credentials and the documented least-privilege role set. The admin role is not required.
• Named human reviewers for both gates. Who signs off a design, and who signs off an evidence package. The platform will not run a change without them.
• Network allow-listing where required. If the instance restricts inbound access, allow-list the published geneworks.ai egress ranges. Single sign-on configuration is handled at the same time.
• Your standards, if you have them written down. Naming conventions, delivery policies and review criteria, to encode as Genes. This is optional on day one and valuable by week three.

Access level follows the module scope agreed per instance. Assessment-only workspaces run with reduced privileges. Delivery and upgrade workflows on sub-production instances typically use a broader role set.

Instance requirements

geneworks.ai supports current and recent ServiceNow releases. The connection test detects your release and patch level and reports anything unsupported before work starts.

Supported modules

Controlled beta means in use with selected customers while remaining product work completes. The beta status is stated before a beta module goes into any scope of work.

Technical requirements

Deep ITOM work, specifically Discovery and Service Mapping, requires those plugins already active on your instance. The platform verifies plugin status and reports gaps before proceeding rather than failing midway.

Connecting an instance

A workspace connects to exactly one ServiceNow instance. Create separate workspaces for dev, test and any other instance in scope.

Start read-only. Connect with a reduced-privilege account first, run the assessment surfaces, see what the platform finds in your own estate, and grant write roles only when you are ready to remediate.

Your first day

The fastest way to see whether this is real is to read, not to build. Every one of these is read-only and changes nothing.

A useful first change is a small one with a real dependency in it: a business rule plus the notification that depends on the event it raises. It exercises the design gate, dependency ordering, both test types and the evidence review in about the smallest scope that still proves the loop works.

Instance policy

geneworks.ai is designed to operate against sub-production ServiceNow environments. You designate which instances are connected and at what access level, and promotion between them follows your own change management process. The platform does not bypass your change process and does not promote to production on your behalf.

Why sub-production first. A production change should always be initiated by a human-reviewed, tested artifact, which is exactly what the platform produces: a named, scoped update set, validated by automated and functional tests, with an evidence package attached, ready for your change advisory board on your terms.

The recommended flow. Build in a development or personal developer instance, promote to test or UAT for stakeholder validation, then commit to production through your normal process.

Tenancy and data handling

Two levels of tenancy

• Organization — each customer receives a dedicated organization in its own single-tenant environment. Every user, workspace, project and record belongs to exactly one organization.
• Workspace — within an organization, each workspace connects to exactly one ServiceNow instance, and everything belonging to that connection is scoped to it.

Every record and every request is scoped to the caller’s organization and workspace, enforced in the authorization layer and, underneath that, by the fact that another customer’s data is not in the same system at all.

What the platform stores

The platform reads instance metadata, configuration records, and where required for testing, test data. Production business records are not required and are not replicated wholesale. Where a configuration record incidentally references a person, for example as a record owner, it is processed transiently for the task at hand.

Encryption and credential custody

• In transit — TLS 1.2+ on every external connection.
• At rest — AES-256 throughout, under customer-managed KMS keys.
• Credentials — instance credentials and OAuth client secrets receive an additional layer of application-level authenticated encryption before storage. Key material exists only in the backend runtime of your own environment, never in the interface tier, in logs, or in source control.
• Platform secrets — injected at deploy time through managed secret storage. Workloads use short-lived, role-based cloud identities rather than long-lived static credentials.

Retention and deletion

Your data is retained for the duration of the subscription. On termination or verified written request, the dedicated environment is torn down and the data deleted, with certification of destruction provided. The customer-managed key model applies here too: revoking the key is a deletion you can execute yourself, on your own timetable.

AI and model usage

• Inference runs over a private, region-pinned path to frontier models. The architecture is model-agnostic and carries no single-vendor dependency.
• No training on customer data. The provider is contractually prohibited from it, and geneworks.ai does not train, fine-tune or improve any model on customer content.
• What is sent for a given operation is scoped to that operation. Customer content is never pooled across tenants for context.
• Per-tenant model constraints can be applied where a customer’s policy requires them.

Security and governance

Governance here is architecture rather than a feature list. The full model, including the architecture and security overview, is available under NDA. In short:

The six commitments

What the platform can and cannot do

Authentication and access control

Connection to ServiceNow uses OAuth 2.0 with customer-supplied credentials, operating as a dedicated integration user under a least-privilege scoped role set. The admin role is not required. Every platform action is attributable to that user and appears in your own ServiceNow audit log.

Inside the platform, users are invited into your organization by an administrator and assigned per-workspace roles. Roles determine both visibility and capability, in particular which users may run read-only analysis and which may initiate build, change and test execution. Users cannot see workspaces they have not been granted.

Network posture

Outbound-initiated only, with no inbound ports on the customer side. The web application is delivered over HTTPS with single sign-on and connects inward through a secure outbound-only tunnel. Inference runs over a private, region-pinned path. Egress IP ranges are published for allow-listing.

Audit and evidence integrity

Every agent action, human approval and deployment is logged with actor, timestamp and payload reference. Evidence is retained immutably against the run that produced it, and both gates record the identity of the approving reviewer. The audit record is the authoritative account of what was built, when, by which agent, at what risk level, and who authorized it.

Shared responsibility

Platform updates are applied by geneworks.ai to your dedicated environment. There is no ServiceNow upgrade, no update set and no change window on your side, which is why the platform can move at a different cadence from the instance it works on.

Packaging and tiers

Commercially the platform is offered as two motions: Enterprise platform and Professional services. Subscription is per named user. Term, seat minimums and rates are agreed jointly. There is no public rate card.

Capability itself is cumulative by depth: each depth includes everything below it, so moving up adds capability rather than replacing it. The three columns below are that depth map, not a third public product family.

AI usage is unlimited under a fair use policy on Professional services. There is no per-token metering, no consumption billing and no usage true-up, so nobody has to ration the platform to protect a budget line. A one-time setup fee applies — enterprise setup on the first motion, per-client setup on the second — reflecting the real work of standing up a dedicated single-tenant environment rather than creating a record in a shared system.

See Pricing for how the two motions are described, or contact us for commercial terms.

Reference

The product lines

Software factory (Plan) · Command Center, Application Explorer, Artifacts. SDLC automation (Build + Verify) · the delivery loop, built-in IDE, App Builder, scoped update sets, ATF Test Center, Validation Center, self-healing tests, evidence and audit store, Process Analyst. Organizational Memory (Optimize) · CMDB Rapid Assessment, Catalog Center, Upgrade Assist, Normalize, Tech Debt Assessment. Ask Gene · present on every screen, not a fourth product.

Quick answers

Intellectual property

A provisional patent application titled Artificial Intelligence System for Continuous Enterprise Software Development and Governance has been filed, covering the continuous delivery and governance architecture described on this page.