Documentation

See everything in your instance. Fix what you see.

The complete reference for GeneWorks — the five products, the delivery loop, the 152-agent workforce, impact analysis, testing, tenancy, and how the platform learns your instance over time. Every product reads first; nothing changes without your sign-off.

Introduction

What is GeneWorks?

GeneWorks is an agentic ServiceNow delivery platform. A coordinated team of 152 specialist agents, orchestrated by Gene, reads your instance, scores what it finds, and — on your approval — designs, builds, tests, documents, and remediates it. Every agent action is scoped, permissioned, and audited. Human practitioners stay in control of what is planned, approved, and promoted.

The platform is organised into five products around one shared engine. Design maps the instance and plans the work. Build turns an approved design into real ServiceNow configuration. Verify tests it and captures the evidence. Optimize scores and remediates catalog, CMDB, data, and upgrade readiness. Ask Gene answers questions and runs governed tasks in plain English. All five read first and write only within an explicit, user-initiated workflow.

152 agents in 5 groups, plus Gene. Strategy & Design, Build, Quality, Documentation & Compliance, and Operations & Knowledge — with 18 further agents maintaining the Normalization reference catalog.
Two human sign-offs. Design review before any code is written; verification review before anything ships. Promotion between instances follows your own change management process.
Read-first by design. Assessment is read-only. Remediation is a separate, reviewed, reversible step packaged as a scoped update set.
ATF and functional coverage. ATF suites are authored alongside the code and run on the GeneWorks runner, with no ServiceNow CloudRunner license required. Browser-driven functional tests capture screenshot evidence on every change.
Fully managed SaaS. No plugin, MID Server, agent, or appliance is installed in your environment, and no inbound connectivity to your network is required.

The platform in one sentence: the assessment tool is also the remediation tool — it shows you what is wrong, and fixes it, with a human on the gate.

Introduction

The Core Pattern

Every GeneWorks surface follows the same four-step shape. Learn it once and the whole suite becomes predictable — the only variable is which part of the instance each product points at.

1 · Scan read-only — reads sys tables, dictionary, audit and config to build a map, a health score, or a set of findings. Writes nothing back. 2 · Score classify — health scores, maturity bands, ranked findings, confidence. 3 · Propose sequence fixes by impact and effort. Each finding carries its own remedy. 4 · Approve you click ("Make it a Change" / "Propose change" / "Apply to instance"). The change runs the governed six-stage loop and is fully reversible.

Because the scan is read-only and completes in seconds, you can point any product at any connected instance and see the current state immediately. Because remediation is explicit and gated, nothing is applied silently, in bulk, or without a named approver.

Introduction

Architecture Overview

GeneWorks is delivered as a fully managed SaaS platform. Platform services run in the GeneWorks AWS environment on Amazon EKS across multiple availability zones; the web application is served from Vercel at app.geneworks.ai. The integration with ServiceNow is SaaS-to-SaaS: GeneWorks calls the ServiceNow REST APIs directly over HTTPS. Your network is never in the data path.

// Request path You browser · session handled at the edge → GeneWorks web app app.geneworks.ai (Vercel) — holds no instance credentials → API & orchestration AWS EKS — authn · authz · audit · the only public backend → Agentic AI runtime AWS EKS (private) — planning & execution, Claude via API → Integration layer AWS EKS (private) — governed tool gateway, credential custody → ServiceNow REST API HTTPS · TLS 1.2+ · OAuth 2.0 or Basic, outbound only → Your ServiceNow instance remains the system of record

Zero footprint in your network. No VPN, site-to-site tunnel, MID Server, installed agent, or appliance. No inbound connectivity to your environment is required.
Single governed egress path. All instance traffic flows through the ServiceNow integration layer, where authentication, scoping, and per-action audit are enforced. AI agents never hold raw instance credentials.
REST-only integration. No plugin, MID Server, or update set needs to be installed on the instance for core operation.
Encrypted throughout. TLS 1.2+ on every external connection; AES-256 at rest across managed PostgreSQL, S3, and compute volumes, with keys managed through AWS KMS.
Internal services are private. The AI runtime, integration layer, verification services, analysis services, and document builder have no public endpoints and are reachable only on the cluster private network.

Your instance stays the system of record. GeneWorks reads configuration and metadata to build maps, scores, and findings. Recovery consists of restoring platform state and re-reading the instance — your ServiceNow data is never held exclusively by GeneWorks.

Introduction

Glossary

Gene — the orchestrator. Routes work across the 152-agent roster, holds authoritative task state, and enforces the two sign-off gates. The only agent you talk to directly.
Product — one of the five surfaces: Design, Build, Verify, Optimize, and Ask Gene.
Organization — your tenant. All users, workspaces, and data belong to exactly one organization; nothing is shared across organizations.
Workspace — a connection to exactly one ServiceNow instance. Credentials, analysis data, run history, and artifacts are scoped to the workspace.
Scan — a read-only pass that maps, scores, or classifies part of your instance. Writes nothing.
Finding — a scored issue with a recommended fix, exportable into a governed change.
The Delivery Loop — the six-stage build path: Requirement → Design → Task Planner → Execute → ATF Tests → Functional Tests, with a human sign-off at Design and at Verification.
Impact / collision analysis — a read-only trace of the blast radius of a change across the dependency graph.
Functional test — a live browser test the agents run: logging in, navigating, filling fields, and capturing screenshot evidence.
Update set — a named, scoped ServiceNow package for the change, reversible via backout. GeneWorks never lands changes in Default.
Compounding memory — instance-specific knowledge the workspace accumulates, so agent proposals track your team's patterns over time.
Honesty principle — GeneWorks reports what it actually completed and hands you a runbook for the rest.

The Product Suite

GeneWorks Design

Plan with clarity.

Design is where an instance becomes legible and a change becomes a plan. It covers blueprints, requirements, architecture, and planning — and it is the entry point for every other product, because nothing should be built against an instance nobody fully understands.

Command Center

Command Center reads your entire instance and renders it as one living graph — every application, table, and shared foundation, and the connections between them. A typical mid-size instance maps to hundreds of tables and thousands of connections.

// Command Center header — a real scan 168 tables · 46 shared foundations · 8,634 connections · mapped 2d ago since last map: +0 −0 · 0 rewired · 1 busier

Five lenses over one graph. Command Center opens on the map and adds:

Lens	What it shows
Map	The full interactive graph. Click any node or edge to open it; drag to rearrange; zoom to reveal tables.
Collisions	Ask what happens if you change something, and the agents trace the blast radius across everything the object connects to.
Dead weight	Unused, orphaned, and duplicated configuration bloating the instance — candidates for retirement.
Activity	What has changed recently, and where the platform is getting busier.
Upgrade	A fast lens on release exposure, feeding UpgradeAssist for the full analysis.

// Example questions against the live graph "What happens if I make priority mandatory on incident?" "What stands on sys_user?" "I'm planning a returns app — sketch it." // Example verdict on a collision query → "If I add a field to Incident, what will be the impact?" 15 objects impacted — SLAs, notifications, business rules, and two integrations.

Tracing 8,634 connections to find the 15 that matter is not hand work. It runs read-only, so you can ask before you touch anything.

Application Explorer

An x-ray of any single application. Explorer reads an app end to end and shows exactly how it is built — out-of-the-box versus modified versus net-new — and where the customizations concentrate. It is the fastest way to understand an app you did not build, and the foundation for an upgrade review.

// Incident Management — a real scan Anchor: incident · ServiceNow Zurich · MANAGED · OOB · GLOBAL 741 artifacts · 1,043 relationships · 7/7 areas scanned 713 baseline (out-of-the-box) 28 customized (baseline, modified) 0 custom (added here) 147 automations (rules · flows · SLAs)

Composition — baseline vs customized vs custom. Here: 713 baseline (96.2%), 28 customized (3.8%), 0 custom — a near-vanilla app.
Artifacts by area — Data model 220 · User interface 117 · Process & automation 147 · Security & access 109 · Reporting 74 · Business logic 68 · Intake 6.
Customization heat map — the upgrade-review view: Security & access 15 · Process & automation 6 · Business logic 4 · Reporting 2 · UI 1.

Every app opens with its own workspace — Overview, Ask Gene, Plan, Configs, Test, Troubleshoot, and Artifacts — plus deep tabs for data model, business logic, user interface, security & access, process & automation, intake, reporting, customizations, relationships, and changes. When the instance changes underneath you, Explorer prompts a re-scan.

Document Builder

Every delivery document, written from live instance state rather than a blank template. Choose a type, answer a short set of questions, and the agents generate a complete, sectioned document you can download as PDF.

Group	Document types
Assess	Health Check Report · Upgrade Assessment Report
Deliver	As-Built Documentation · Data Dictionary · Integration Specification · Runbook · Security & Access Design · Standard Operating Procedure · Statement of Work · Technical Design Document · Test Plan

Documentation is a side effect, not a chore. The same evidence the delivery loop produces on every change feeds the documents, so undocumented changes are a property the platform prevents rather than a discipline you enforce.

The Product Suite

GeneWorks Build

Automate with speed.

Build turns an approved design into real ServiceNow configuration. It follows a full product development lifecycle — plan, build, configure, test, document, release — for both out-of-the-box applications (ITSM, CMDB, Service Catalog, and related platform applications) and custom scoped applications.

Real code, readable in place. Agents write ServiceNow artifacts you can read and edit in the built-in IDE. Load-bearing decisions are recorded, not buried.
Dependency-ordered execution. The task planner decomposes the approved design into granular tasks with explicit dependencies, and agents build in that order.
Tests and docs authored alongside. ATF suites and delivery documentation are produced with the build, not bolted on afterwards.
Packaged for review. Every change is delivered as a named, scoped update set, ready for your change process.

Writes are a distinct operation class. Read and analysis operations and write operations are separated in the integration layer. Writes occur only inside an explicit, user-initiated workflow, in a workspace where the user holds the required role.

The Product Suite

GeneWorks Verify

Deliver with confidence.

Verify tests every change two ways and captures the evidence as it runs. GeneWorks 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 with the build and executed on the GeneWorks runner. No ServiceNow CloudRunner license is required. Tests are stored in your instance; you own them.
Functional Test — an agent opens a real browser, logs in with the service account, navigates to the relevant form, fills the mandatory fields, and captures screenshot evidence at each step. It does not mark a failing test as passed.

// A functional test, as it runs → launching browser session → logging in as agent (no human) → navigating to incident.form → filling mandatory fields · selecting caller → capturing evidence · screenshot 4/4 ✓ PASS — all assertions green

The Self-Healing agent repairs known-pattern failures automatically through one-click Fix ATF and Fix FT. What it cannot repair is flagged for a human. Every functional test attaches its screenshots to the story, so verification is a review of proof rather than a leap of faith.

The Product Suite

GeneWorks Optimize

Optimize processes and performance.

Optimize scores the parts of the platform that quietly degrade — catalog quality, CMDB health, reference data, and upgrade readiness — and turns each finding into a governed change. Four surfaces, one pattern.

CMDB Assessment

A full CMDB maturity assessment — health score, findings, and a sequenced roadmap — from a read-only scan that takes about 12 seconds. Four tabs: Executive Readout, CSDM Practices, Findings → Roadmap, and Scan History.

Level	CMMI	What it means
Know Your Devices	CMMI 1 · Initial	Poor or non-existent management; no reliable inventory. CIs cannot be trusted for routing or impact analysis.
Federated CMDB	CMMI 2	Basic processes and documentation; multiple uncoordinated sources. The typical near-term target.
Global Operating Model	CMMI 3	Standardised, documented processes; assets tracked through their lifecycle.
Service Awareness & Automation	CMMI 4	Value measured; performance monitored; processes integrated with the business.
CMDB by Design	CMMI 5	Data drives strategic decisions; continuous-improvement framework in place.

Completeness — mandatory and recommended attributes scored separately, because a missing mandatory field is a broken process while a missing recommended field is unrealised value.
Correctness — three signals: stale CIs (not refreshed in 60 days), orphan CIs (no relationships), and duplicates, detected with class-aware identification rather than name matching.
Compliance — shown only where it can be measured read-only; otherwise flagged as requiring an audit job rather than counted as zero.

// Findings → Roadmap (an example scan, score 31/100 → target 50) DO FIRST (low effort · high impact) F1 · Correctness Stale CIs — not refreshed in 60 days Q1 F7 · Governance CMDB Health has never produced results Q1 MED EFFORT (high impact) F4 · Completeness Mandatory attributes missing — no CI owner Q1–Q2 F6 · Consumption CMDB under-consumed — incidents carry no CI Q2 BIG BETS (high effort · high impact) F2 · CSDM Not service-aware — infra not tied to service Q2 F3 · Correctness Orphan CIs — no relationships Q2

Catalog Center

Scores every catalog item and states exactly what to fix. Each item is rated on three pillars; the composite is the equal-weighted mean of the pillars that could be scored, and every recommended fix carries the score it will recover.

Pillar	Measures
Build Quality	Technical debt and maintainability — how much custom logic hangs off the item.
Experience	Form length, guidance, and real usage — is anyone actually ordering it?
Governance	Ownership, documentation, duplication — is it owned, documented, and unique?

// A scored item "IAR Configuration CRP" score 53 · NEEDS ATTENTION Build Quality 58 · Experience 50 · Governance 50 · Workflow n/a Recommended fixes — fixing all 7 recovers ~142 points 1 · More customisations than the item needs HIGH Build Quality +30 17 active customisations (12 client scripts, 5 UI policies). Ceiling is 2. 2 · No fulfilment group assigned HIGH Governance +30 3 · Published but unused MED Experience +20 (0 orders / 30 days) 4 · Variables lack documentation MED Governance +20 (0 of 44 documented)

Every fix carries Ask Gene to explain it and Propose change to turn it into a governed change. You can also author new catalog items and update existing ones from inside Catalog Center.

Normalization

Cleans company, vendor, software, and asset data against a GeneWorks-curated global catalog of publishers, products, versions, and lifecycle data — kept current by 18 dedicated agents — and applies results to your instance only on your approval.

// A normalization run — companies & vendors, source core_company Raw records 177 · Unique variants 115 · Canonical records 176 Match rate 75.7% · Auto-accepted 84 · Needs review 45 RAW VALUE NORMALIZES TO REFS CONFIDENCE METHOD Apple Apple Inc. 1,453 99% ALIAS Dell Inc. Dell Technologies Inc. 644 99% ALIAS Microsoft Microsoft Corporation 370 99% ALIAS

High-confidence matches auto-accept; the rest enter a review queue where you accept, reject, or escalate each variant. Accepting a match approves a proposal — your instance data changes only when you apply the accepted candidates. Matching rules, the canonical catalog, record lifecycle, and a replayable run history are all under your control.

UpgradeAssist

Tells you what will break before you upgrade. UpgradeAssist pins the release knowledge for your target version at kickoff, then cross-references every documented change between your current and target release against your live instance, read-only.

// An upgrade assessment Upgrade path: Zurich → Australia · Detected: Zurich · Patch 10 Release knowledge: v10 (pinned at kickoff) · 335 tables read · 27 analyses 974 changes checked, grouped by app: 7 blockers 41 affected 2 could not verify 91 manual review 145 not applicable 150 clear 538 informational

Blockers are surfaced first and grouped by app, so remediation is scoped before the upgrade begins. Findings & Fixes carries recommended remediations, each exportable into a governed change. Re-verify re-reads only the items that could not be verified and leaves settled classifications untouched. UpgradeAssist also reads sys_upgrade_history_log, so previously skipped customizations do not silently re-break on the next upgrade.

The Product Suite

Ask Gene

Get anything done.

Ask Gene is the conversational interface to the platform, available across the suite and inside every product. Ask a question about the connected instance, investigate configuration, generate documentation, or initiate a governed workflow in natural language. Gene classifies intent and routes to the right specialists.

You say	Gene routes to
Incident, Problem, Change, SLA, Catalog, Knowledge, Request	ITSM specialists
Discovery, CMDB, CI, Service Mapping, Event, Alert	ITOM specialists
ACL, Role, License, User, Audit, Performance, Admin	Platform & SecOps specialists
REST, API, webhook, IntegrationHub, Jira, Slack, SCCM	Integration specialists

Ask Gene inherits the same governance as every other surface: read operations answer directly, and anything that would write your instance becomes a proposed change subject to the two sign-off gates.

The Delivery Loop

The Six Stages

When you make a change — or accept a finding from any product — it runs the same six-stage loop. Each stage produces a discrete, auditable artifact, and two of them are human gates.

1 · Requirement (auto) — input (a story, a CSV, plain English, or an exported finding) becomes a structured, versioned requirement. Gene asks clarifying questions where the requirement is thin. Output: versioned spec.
2 · Design (human sign-off) — a full solution design: data model, dependencies, ACL implications, integration shape, exact artifacts, and an explicit list of assumptions. Impact analysis runs in parallel. Your architect signs off before anything is built, and a named approver is recorded.
3 · Task Planner (auto) — the approved design is decomposed into a granular, ordered plan: every table, rule, notification, and test as its own task, with dependencies between them. Regenerate or adjust before a line is built.
4 · Execute (parallel) — agents build the tasks in dependency order, writing real ServiceNow code you can read in the built-in IDE, and carrying load-bearing decisions through explicitly. ATF and documentation are authored alongside.
5 · ATF Tests (auto) — server and client suites, authored with the build and run on the GeneWorks runner. No CloudRunner license.
6 · Functional Tests (human sign-off) — live browser tests with screenshot evidence. A human reviews the evidence package and signs off before the change closes.

The Delivery Loop

A Change, End to End

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

// CH-001 · Task Planner · 5 tasks TSK-001 Register the incident.vip.prioritised platform event DONE business-logic · event-registration · independent TSK-002 Before-insert BR on incident: VIP auto-prioritise + event DONE business-rule · WAITS ON TSK-001 TSK-003 Email Notification: VIP incident prioritised — confirmation DONE notification · WAITS ON TSK-001 TSK-004 ATF test (records): VIP auto-prioritise, guard, work note DONE atf-test · independent TSK-005 Functional Test — browser-driven use case DONE // Load-bearing decisions carried through to Execute → Priority is Data-Lookup managed — the BR is ordered AFTER the OOB Priority Lookup, and the executor live-probes that current.priority survives it. → Event-driven email, not a condition — guarantees the caller email fires even for the already-Critical case (a CHANGESTO condition would miss it). → Prerequisites flagged: outbound SMTP, sn_atf.runner.enabled on dev/test.

The planner does not just list tasks. It reasons about execution order, edge cases, and prerequisites, and records that reasoning so a human reviewer can check it at the Design gate.

The Delivery Loop

Human Sign-Offs

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

Gate	When	What you do
Design review	After Design, before Execute	Approve the solution design and its assumptions. Nothing is built until a named human approves. Medium and high risk require an explicit sign-off on the risk level.
Verification	After Functional Tests, before close	Review the evidence package — ATF results, functional screenshots, the named change — and sign off. Nothing reaches your change process unseen.

The honesty principle. Between the gates, GeneWorks reports what it actually did. Out of 100 stories it might complete 73 and hand you a clean runbook for the remaining 27. The two gates exist precisely because some work belongs to humans.

The Delivery Loop

Impact & Collision Analysis

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

Area	Code	What gets assessed
Business Rules & Logic	H1	Rules that may conflict or be triggered — execution order, conditions, table interactions.
SLA Timers	H2	Active SLAs whose timing or fields overlap; category, priority, and assignment changes are high-sensitivity.
Assignment Groups	H3	Group config, membership, and routing logic.
Approval Workflows	H4	Active workflow and Flow Designer approvals; open approval records that could be disrupted.
CMDB Records	H5	CI relationships affected, especially the cmdb_ci hierarchy.
Active Records	H6	Live records in scope — open incidents, active changes, in-flight requests.
Integration Points	H7	Outbound and inbound REST and IntegrationHub spokes touching affected tables or fields.
Security & ACLs	H8	ACLs, roles, and field-level security; flags any access expansion or restriction.

Risk triage. LOW: all dimensions below threshold; proceeds after design sign-off. MEDIUM: one or more elevated; the build pauses mid-execution for your review. HIGH: critical risk; the build does not start until you rescope or authorise explicitly.

Dependency awareness compounds. Every completed change records the dependencies it touched, so a future change to a related object surfaces as a blast-radius risk even when the person making it does not know the connection exists.

The Delivery Loop

ATF & Functional Testing

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

ATF — suites are authored at stage 4 alongside the build, executed at stage 5, and stored in your instance. No ServiceNow CloudRunner license is required.
Functional — browser-driven tests run at stage 6, producing the screenshot evidence package the verification gate reviews.
Self-healing — known-pattern failures are repaired and re-run automatically; anything else is flagged for a human rather than retried blindly.

A test is never marked passed if it failed. Evidence is captured as the work runs, so verification is a review of proof rather than a report of intent.

The Delivery Loop

Update Sets & Rollback

Every change is delivered as a named, scoped ServiceNow update set — the native mechanism for packaging and transporting configuration between environments.

// Naming pattern GENE_{MODULE}_{FEATURE}_{YYYYMMDD} // Examples GENE_ITSM_P1_ESCALATION_NOTIFICATIONS_20260722 GENE_ITSM_VIP_AUTO_PRIORITISE_20260722 GENE_ITOM_CMDB_CI_RELATIONSHIP_RULES_20260715 // Always scoped — never Default (enforced, cannot be overridden)

Preview and commit. Import the update set into your target environment, preview, resolve any flagged conflicts, and — after your change approval — commit; all changes apply in a single audited transaction. Rollback. Any update set can be backed out after commit, and GeneWorks preserves before and after state for verification.

Rollback removes configuration, not data. Update set backout reverses configuration artifacts such as business rules and SLA definitions, not data changes made during their operation. Plan rollbacks accordingly.

Getting Started

Prerequisites

Onboarding needs four things. No plugin, MID Server, or install is required for the core platform.

ServiceNow instance(s). You designate the instance or instances to connect, typically starting with sub-production, each reachable at https://<instance>.service-now.com.
An integration identity per instance. A dedicated integration user — never a personal account — using either an OAuth 2.0 application registration (client ID and secret, recommended) or Basic authentication credentials.
Organization setup. Named users by work email, invited into your GeneWorks organization. An organization administrator assigns per-workspace roles.
Optional network controls. IP allowlisting of the GeneWorks static egress addresses on the ServiceNow instance. Addresses are provided during onboarding.

Access levels follow the module scope agreed for each instance. Assessment-only workspaces can run with reduced privileges; delivery and upgrade workflows on sub-production instances typically use an admin-level integration account.

Offboarding is symmetrical. You disable the integration identities, and GeneWorks deletes organization data on the retention schedule in Tenancy & Data Handling.

Getting Started

Instance Requirements

GeneWorks supports current and recent ServiceNow releases. No additional plugins are required for the core platform; the connection test detects your release and flags anything unsupported.

Release	Status	Notes
Zurich	Fully supported	Current release. Recommended.
Yokohama	Fully supported	All features available.
Xanadu	Fully supported	All features available.
Washington DC	Fully supported	All features available.
Vancouver and older	Partial	Core scanning may work; upgrade to Washington DC or later for full coverage.

Some deep ITOM work — Discovery and Service Mapping — requires those plugins already activated on your instance. GeneWorks verifies plugin status and reports gaps before proceeding.

Getting Started

Connecting Your Instance

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

1 · Register the integration. For OAuth 2.0, register an application in the ServiceNow Application Registry and note the client ID and secret. For Basic authentication, provision a dedicated integration user.
2 · Create the workspace. Enter the instance URL — https://your-instance.service-now.com, no trailing slash or path.
3 · Provide the credentials. GeneWorks manages OAuth token acquisition and refresh. Secrets receive application-level AES-256-GCM encryption before storage, on top of database encryption at rest.
4 · Test the connection. GeneWorks verifies reachability, authenticates, and detects the release.
5 · Scan. Command Center maps the instance and the assessment surfaces are ready immediately.

You hold the kill switch. Disabling the integration user or the OAuth application in ServiceNow immediately severs GeneWorks access. Credentials can be rotated or revoked at any time.

Start read-only. Connect with a reduced-privilege account first, run the assessment surfaces, and grant write roles only when you are ready to remediate.

Getting Started

Your First Scan

The fastest way to see value is to read, not to build. Point a surface at your instance and see the current state. All of these are read-only.

// Day-one scans, all read-only → Command Center map the whole instance, find collisions & dead weight → Application Explorer x-ray any app: baseline vs customized, hot spots → CMDB Assessment health score + maturity + roadmap in ~12 seconds → UpgradeAssist what breaks on your next upgrade, before you start → Catalog Center score every catalog item, ranked by points to recover // Then, when you're ready to fix: Accept a finding → the six-stage loop → your two sign-offs → done

Getting Started

Instance Policy

GeneWorks is designed to operate in sub-production ServiceNow environments. You designate which instances are connected and at what access level, and promotion of work between instances follows your own change management process. GeneWorks does not bypass your change process and does not promote to production on your behalf.

Why sub-production first. Production changes should always be initiated by a human-reviewed, tested artifact — which is exactly what GeneWorks produces: a named, scoped update set, validated by ATF and functional tests, ready for your change advisory board and production commit on your terms.

Recommended flow. Build in dev or a personal developer instance, promote the change to test or UAT for stakeholder validation, then commit to production through your normal change process.

Two independent audit trails. Every GeneWorks operation is attributable to the integration user in your instance's native audit trail (sys_audit, transaction logs), in addition to the platform's own append-only audit records. You retain full independent visibility of every action performed.

Platform

The Agent Workforce

GeneWorks runs 152 specialist agents, orchestrated by Gene, in five groups — plus 18 agents dedicated to the Normalization reference catalog. Every group works on the same workspace: agents see each other's output and share context.

Group 1 · Strategy & Design — Functional Consultant, Solution Architect, Platform Architect, Process Designer, Integration Lead. Own the requirement, design, and dependency mapping that go to design sign-off.
Group 2 · Build — ITSM, ITOM, CSM, HRSD and SecOps specialists, GRC Analyst, ServiceNow Developer, Scoped App Engineer, Flow Designer Specialist, IntegrationHub Engineer, Service Portal Developer.
Group 3 · Quality — ATF Tester, Selenium Tester, QA Engineer, UAT Analyst, Performance Engineer. Generate coverage in parallel with the build and assemble the evidence package.
Group 4 · Documentation & Compliance — Genewriter, GeneDocs, Compliance Advisor, Release Manager, Change Coordinator.
Group 5 · Operations & Knowledge — CMDB Steward, Knowledge Curator, Evidence Collector, Self-Healing Agent, Dependency Mapper, Workspace Coordinator, and Gene.

Agent skill chain. Every build agent runs an identical internal chain of five roles — Architect (system design and impact) → Functional (stories and acceptance criteria) → Coder (writes and executes ServiceNow code via REST) → ATF Tester (writes and runs ATF) → Selenium Tester (browser validation) — so each produces a complete, tested artifact rather than a fragment.

Platform

Gene & Orchestration

Gene is the orchestrator and the only entity you interact with directly. It classifies intent, routes to the right specialist, enforces the two gates, synthesises outputs, and holds authoritative task state. Active locks prevent concurrent conflicting changes on the same resource.

Agents reach ServiceNow only through the governed integration layer — a controlled set of scoped operations — never with raw credential access. Every agent action is recorded with organization, workspace, user, timestamp, operation, and target.

AI capability is provided by Anthropic Claude models via the Anthropic API under commercial terms. All model interaction is server-side within the GeneWorks environment; you do not need an Anthropic account or key.

Platform

Memory & Learning

The agents get more reliable the longer they run on your instance. Three mechanisms drive it.

Compounding workspace memory

Your idioms, ACL patterns, integration map, and prior decisions accumulate in the workspace. Effort reduction climbs from a cold start toward a steady state as agent proposals converge on your team's patterns.

Phase	Window	Effort reduction
Cold start	Week 1–4	25–35%
Context maturing	Month 2–3	40–50%
Compounding gains	Month 4–6	55–60%
Steady state	Month 6+	~65%

Training corpus

The agents draw on the ServiceNow knowledge surface — product documentation, upgrade and release notes, product fixes and known errors, community notes, partner methodologies, support documentation, and GeneWorks delivery IP — retrieved by semantic similarity, so designs and code follow documented practice.

Self-healing and lessons learned

When a build or test fails on a known pattern, the agents repair and re-run it. Every failure is written to a lessons-learned record the agents read before acting, so repeated errors on your instance decline over time and fewer failures reach a human.

Workspace memory is scoped to your organization. Analysis data, run history, and lessons are stored per workspace and are never pooled across tenants or used as model context for another customer.

Platform

Tenancy & Data Handling

Two-level tenancy

Organization (tenant) — each customer receives a dedicated organization. All users, workspaces, and data belong to exactly one organization; nothing is shared across organizations.
Workspace — within an organization, each workspace connects to exactly one ServiceNow instance. Instance credentials, analysis data, run history, and artifacts are scoped to the workspace.

Every data record and every API request is scoped to the caller's organization and workspace, enforced in the platform authorization layer. Cross-tenant access is not possible by design.

What GeneWorks stores

Category	Stored?	Where
Account data — user names, work emails, membership, roles	Yes	PostgreSQL
Instance connection data — instance URL, integration credentials, OAuth secrets	Yes, application-layer encrypted	PostgreSQL
Configuration and analysis data — application and plugin metadata, configuration records, CMDB structure and quality metrics, test definitions and results	Yes	PostgreSQL + S3
Generated artifacts — assessments, designs, runbooks, upgrade reports, release documents	Yes	S3
End-user or employee PII from the instance	Not collected as a product function	—
Payment data	No	—

GeneWorks processes configuration and metadata, not employee or consumer datasets. Where instance records incidentally contain user references — record ownership, for example — they are processed transiently for the task at hand.

Encryption and credential custody

In transit — TLS 1.2+ on every external connection: browser to UI, UI to API, GeneWorks to ServiceNow, GeneWorks to Anthropic.
At rest — AES-256 across managed PostgreSQL, S3 server-side encryption, and encrypted compute volumes, with keys managed through AWS KMS.
Credentials — ServiceNow credentials and OAuth client secrets receive an additional layer of application-level AES-256-GCM authenticated encryption before being written to the database. Key material exists only in the backend runtime; it is never present in the UI tier, in logs, or in source control.
Platform secrets — injected at deploy time via managed secret storage. Workloads use short-lived, role-based cloud identities rather than long-lived static credentials.

Residency, retention, and deletion

Platform data is hosted in the United States by default; alternative regions can be discussed as part of enterprise onboarding. Customer data is retained for the duration of the subscription. On termination or verified written request, GeneWorks deletes your organization data — including stored credentials, analysis data, and generated artifacts — within 30 days, with backups expiring on a rolling schedule thereafter. Deletion confirmation is provided on request.

AI and model usage

All AI functionality uses Anthropic Claude models via the Anthropic API. No self-hosted, open-weight, or consumer AI services are used.
No training on customer data. Under Anthropic's commercial terms, API inputs and outputs are not used to train Anthropic's models.
Data sent to the model is task-scoped: only the configuration records, analysis output, or document context needed for the specific operation. Customer data is not pooled across tenants for model context.

Subprocessors

Subprocessor	Purpose	Region
Amazon Web Services	Compute (EKS), storage (S3), networking, KMS	US (default)
Supabase	Managed PostgreSQL — platform database	US (default)
Vercel	Web application hosting and CDN; no instance credentials	Global edge, US origin
Anthropic	AI model inference (Claude); not used for training	US

Material changes to this list are communicated to customers in advance.

Platform

Security & Governance

Governance is the architecture, not a feature. The full model is in the Security page and the Solution Architecture & Security Overview, available under NDA. In short:

Capability	Can do	Cannot do
Scanning	Read the instance to map, score, classify	Write anything during a scan
Changes	Design, build, test, and package on approval	Promote between instances outside your change process
Credentials	Store encrypted, rotate, and use through the integration layer	Expose raw credentials to AI agents or the UI tier
Update sets	Create, name, scope, manage	Commit to production — that is your action
Testing	Write and run ATF and functional tests	Mark a failing test as passed
Sign-offs	—	Bypass the two human gates

Access control

Users are invited into your organization by an organization administrator and assigned per-workspace roles — administrator, operator, viewer. Roles determine both visibility and capability, in particular which users may run read-only analysis versus initiate build, change, and test execution workflows. Users cannot see workspaces they have not been granted, and can never access another customer's organization. Multi-factor authentication and enterprise SSO (SAML 2.0 / OIDC) are on the near-term roadmap.

Infrastructure and operations

Workloads run on Amazon EKS across multiple availability zones in private subnets. The only internet-facing backend component is the load-balanced API endpoint, fronted by managed TLS termination, AWS WAF, and AWS Shield.
Least-privilege IAM per service, security groups restricting east–west traffic, and no public endpoints on internal services.
Centralized application and infrastructure logging with health and anomaly alerting. Secrets and credentials are excluded from logs by design.
All changes flow through version control and peer review before deployment; production deploys are automated and traceable to reviewed commits. Customer data is not used in development or testing.
Dependency and container image vulnerability scanning in CI, with risk-prioritized patching. An independent penetration test is scheduled, with an annual cadence thereafter; a summary letter is shared under NDA on completion.

Resilience and incident response

Multi-AZ deployment with stateless services that reschedule automatically on node or zone failure. Databases take automated daily backups with tested restore procedures; object storage uses S3 durability with versioning. Because your ServiceNow instance remains the system of record, recovery consists of restoring platform state and re-reading the instance.

GeneWorks maintains a documented incident response process with severity classification, on-call ownership, and post-incident review. Customers are notified of any confirmed security incident affecting their data without undue delay and within 72 hours of confirmation, including scope, impact, and remediation.

Shared responsibility

Responsibility	Owner
Security of the SaaS platform — infrastructure, application, data stores	GeneWorks
Encryption and custody of stored instance credentials	GeneWorks
Governance and audit of agent actions on the platform	GeneWorks
Subprocessor management	GeneWorks
Provisioning and lifecycle of ServiceNow integration users and OAuth apps	Customer
Selection of connected instances and their access levels	Customer
Content and data hygiene of connected instances	Customer
User and role management within your organization	Customer
Change management and promotion decisions	Customer

Compliance posture

The GeneWorks control environment is designed in alignment with SOC 2 and ISO/IEC 27001 control objectives; certification status and roadmap can be shared under NDA. Subprocessors hold industry-standard attestations, which GeneWorks reviews as part of vendor management. GeneWorks completes customer security questionnaires — SIG, CAIQ, or customer-specific formats — and supports technical deep-dive sessions as part of vendor onboarding.

Audit trail. Every action is logged in a structured record: the entity created, modified, or deleted; an ISO-8601 timestamp; the responsible agent; the risk level; and the before and after state. This is the authoritative record of what was built, when, by which agent, and at what risk.

Platform

Reference

The products: GeneWorks Design · GeneWorks Build · GeneWorks Verify · GeneWorks Optimize · Ask Gene.

The surfaces underneath them: Command Center, Application Explorer, and Document Builder (Design) · Application Product and the delivery loop (Build) · ATF Test Center and Functional Test (Verify) · Catalog Center, CMDB Assessment, Normalization, and UpgradeAssist (Optimize).

Licensing: per seat, all-inclusive, in a bring-your-own-model tier or a fully managed tier with the model included. Each connected client environment is licensed separately. Contact gene@geneworks.ai for current commercial terms.

Supported releases: Zurich, Yokohama, Xanadu, and Washington DC fully supported; older releases partial. Setup: connect in under an hour; first scan the same day.

Deployment: fully managed SaaS in the GeneWorks AWS environment. Data residency in the United States by default.

Need the live walkthrough? See How It Works for the loop and the gates, or Platform Capabilities for the product-by-product breakdown. For vendor security review, request the Solution Architecture & Security Overview at gene@geneworks.ai.