SuiteCentral 2.0 (overview)

An AI integration governance layer for ERP — production-grade, 16 modules, six production connectors, NetSuite + Business Central, built to make AI-powered ERP integration safe, explainable, and compliant.

What it is — two framings that coexist

The corpus offers two distinct framings for SuiteCentral 2.0 and both are accurate, used for different audiences and contexts.

Framing 1: The enterprise integration platform (per 01-executive-summary slide 1):

“SuiteCentral 2.0, an enterprise integration platform built for Squire Advisory. A production-grade package with measurable test evidence, governed AI workflows, and a 16-module footprint across core and extension capabilities.”

This framing emphasizes breadth — 16 modules, 12 core + 4 extension, covering the operational surface of a CPA firm’s integration workload. It is the framing used in the 10-slide executive summary.

Framing 2: The AI integration governance layer (per read-talking-points talking point #1):

“SuiteCentral 2.0 is an AI integration governance layer — it makes AI-powered ERP integration safe, explainable, and compliant.”

This framing is narrower, more distinctive, and explicitly competitive. It is the framing used in the Leadership Talking Points for Jonyce Bullock and Reuben Cook, and it aligns with the “why now” thesis — that the market is moving from AI access as moat to AI governance as moat.

How to use each framing:

• Use Framing 1 when describing what the platform does — breadth, 16 modules, the functional footprint.
• Use Framing 2 when describing why it’s distinctive — the governance depth is the moat, not the AI access.

Architectural positioning — the “middle intelligence layer”

Per ai-governance-layer-video (00:57-01:15), SuiteCentral 2.0 positions itself architecturally as a control plane between AI clients and native ERPs:

“SuiteCentral 2.0 is the middle intelligence layer. We don’t replace the ERPs but act as the control plane between AI clients like ChatGPT and native ERPs like NetSuite. Our role is to make it safe for AI to operate within the ERP by applying policy and governance.”

This is a significant framing choice. SuiteCentral 2.0 is explicitly not competing with NetSuite or Business Central — it is a mediation layer that sits between upstream AI agents (ChatGPT, Claude, Oracle AI, etc.) and the downstream ERP systems. The control-plane language is deliberate: all AI-to-ERP traffic flows through SuiteCentral 2.0, which applies policy, authentication, and governance before any change touches the native ERP.

The MCP (Model Context Protocol) bridge is the implementation of this architecture:

“Suite Central acts as the bridge and gatekeeper. All external AI access flows through our router, applying policy, authentication, and governance before interacting with native ERP servers like NetSuite and Business Central.” — ai-governance-layer-video 01:53-02:06

The four enterprise safety mechanisms (per ai-governance-layer-video 02:06-02:22)

The video names four specific architectural components that together make up the governance layer:

#	Mechanism	What it does
1	Reasoning Trace Engine	Logs justifications for every AI decision
2	Governance Pacer	Prevents throttling (respects NetSuite API concurrency limits, per reuben-cook)
3	DLP PII Shield	Redacts sensitive data before it leaves the governance boundary
4	Approved To Apply	Provides cryptographic verification of human sign-off before any AI-proposed change goes live

These four names are specific and falsifiable. The Governance Pacer confirms the earlier mention in read-talking-points (Reuben’s architecture angle). The “Approved To Apply” mechanism is the cryptographic implementation of the human-approval gate that read-elevator-pitch described functionally.

The four governance capabilities (per read-elevator-pitch Beat 2)

The 90-second pitch is specific about what “governance depth” actually means in terms of runtime behavior:

“It doesn’t just map fields — it explains why, scores its confidence, detects hallucinations, and requires human approval before any change goes live.”

Four concrete runtime behaviors:

1. Explanation — the AI can explain why it made each decision, in a form suitable for an auditor. (Related architectural claim: “Reasoning traces persisted to database” — per read-elevator-pitch Beat 3.)
2. Confidence scoring — each AI decision comes with an explicit confidence number, not a binary “done / failed.”
3. Hallucination detection — the system actively looks for and flags cases where the AI has produced plausible-but-wrong output.
4. Human approval gate — no AI-proposed change goes live without a human approving it first.

These four capabilities together define the “governance layer” framing. They are specific enough to verify against the AI Features Complete Guide, AI Reasoning Traces Guide, and Natural Language Action Gate Tutorial sources (all in the notebook, none yet ingested).

The codebase lives in the Preston-Test repo.

The competitive thesis (per read-talking-points and ai-governance-layer-video)

“Oracle just launched native AI field mapping. OpenAI just launched Frontier. Everyone is building AI integration. Nobody is building AI integration governance. That’s the gap we own.” — read-talking-points

“The world changed last week. The launch of OpenAI Frontier and Oracle’s native AI iPaaS means the old problem of connecting systems is solved. The new strategic shift is, how do we govern the AI that connects them? Speed without control is now a liability.” — ai-governance-layer-video 00:20-00:40

Both sources frame the pitch around the same strategic inflection: AI-powered integration is now table-stakes (thanks to Oracle, Microsoft, and OpenAI shipping native capability), so the moat moves from AI access to AI governance.

Three specific competitor critiques from ai-governance-layer-video (00:45-00:49):

• Oracle’s native AI is a black box (no auditable reasoning)
• OpenAI lacks controls (no policy layer between the model and the ERP)
• Celigo lacks governance-first AI (per read-talking-points)

For the full date-stamped competitive register (Celigo, Boomi, MuleSoft, Oracle NSIP, MCP ecosystem, pricing bands, regulatory anchors), see The Competitive Landscape.

The time-to-close claim (per ai-governance-layer-video 04:05):

“The market window is 6 to 12 months. The technology is verified, the market is open, and Squire is positioned to capture this value.”

⚠ Style-guide tension: 26-canonical-metrics-and-wording explicitly says to avoid “Uncontested 6-12 month window” phrasing unless source-locked and dated. The hook video’s wording is very close to the avoid-list phrasing. This is a wording-governance violation, not a factual contradiction — the claim might still be true but the phrasing should be date-anchored (e.g., “based on competitive landscape as of March 2026”) when used in executive-facing material. See canonical-metrics for the full style guide.

And the competitive lead time (per ai-governance-layer-video 02:56):

“Suite Central 2.0 has 95% live AI field mapping accuracy today, while competitors have it on a roadmap for late 2026.”

These are specific and falsifiable claims: SuiteCentral 2.0 is claimed to be ~6-12 months ahead of competitor capabilities on field mapping accuracy.

Per the same source, what SuiteCentral 2.0’s AI specifically does that Oracle’s native AI does not:

• Explains its reasoning to auditors — reasoning traces are persisted and reviewable
• Respects ERP governance limits — see Reuben Cook’s “Governance Pacer” angle
• Protects PII — DLP-aware
• Works across NetSuite AND Business Central — the dual-ERP story (relevant to the HintonBurdick acquisition)

Why it matters (to the adoption case)

This is the thing being proposed. Every other page in the wiki either describes a part of SuiteCentral 2.0, presents evidence supporting it, or provides context about the customer (Squire) being asked to adopt it.

The core claim

“The differentiator is not one feature. It is the combination of data governance, embedded workflow intelligence, and governed execution in one operating model.” — 01-executive-summary slide 2

This is the central pitch. The argument is combinatorial: don’t focus on individual features; the moat is the combination.

Module breadth (and the “six connectors” distinction)

16-module footprint, decomposed (per 01-executive-summary slide 3 and definitively mapped by 22-module-library) as:

• 12 core operational modules: SupplierCentral, PaymentCentral, CustomerCentral, MDMCentral, SyncCentral, QualityCentral, PayoutCentral, InstallerCentral, ServiceCentral, InventoryCentral, FinanceCentral, ContractCentral
• 4 extension/platform modules: WorkflowCentral, PortalCentral, Vendor Portal, Context Sidecar (labeled “platform demo”)

See module-library for the full catalog with one-line descriptions and evidence routing patterns.

The 6 production connectors are now NAMED (per 26-canonical-metrics-and-wording canonical wording): NetSuite, Business Central, Salesforce, HubSpot, ShipStation, Oracle. They span ERP (NetSuite, Business Central, Oracle), CRM (Salesforce, HubSpot), and logistics/shipping (ShipStation). Note that Oracle appears as a connector here even though it also appears as a competitor in oracle-comparison — these are different Oracle products (SuiteCentral 2.0 connects TO Oracle as a data source; SuiteCentral 2.0 differentiates AGAINST Oracle NSIP as a competitor).

Connectors ≠ modules. Connectors are the external-system integrations SuiteCentral 2.0 ships with; modules are the product’s internal functional decomposition. Both numbers are accurate.

Tier 1 / Tier 2 evidence taxonomy (per narration-scripts scene2-intro)

The scene2-intro narration introduces an organizing framework for the evidence reviewers encounter in the package:

Tier	Anchor	Evidence examples
Tier 1	Governance	Reasoning traces, compliance exports, competitive proof
Tier 2	Execution	Sidecar intelligence, action gating, integration readiness

This is not a claim about what SuiteCentral 2.0 does; it’s an organizing framework for what reviewers should look at when evaluating it. Tier 1 evidence answers “can I trust this?” (governance). Tier 2 evidence answers “does this actually work?” (execution). Both are required for a pilot approval — the CFO and CTO care more about Tier 1; the COO cares more about Tier 2.

The three-review-paths Paths A/B/C each surface both tiers, but weighted differently: Path A (Executive) is lighter on Tier 2 walkthroughs; Path C (Deep Proof) covers both tiers exhaustively. Path B (Leadership, recommended) is balanced.

Seven-scene storyboard structure

Per narration-scripts (via the executive-reel and storyboard-overview narrations), the Watch track’s hero content is organized as a seven-scene narrative that moves from problem to solution to proof to opportunity:

Scene	Title	Purpose	Narration source
1	Problem	AI pressure rises while manual mapping stays brittle	scene1-problem
2	SuiteCentral Intro	Async-first review, Watch/Click/Read tracks, Tier 1/2 evidence	scene2-intro
3	AI Field Mapping	Confidence scoring, explainable reasoning, high/low routing	ai-field-mapping
4	Governance and Compliance	SOC 2 mapping, evidence export, Oracle comparison	scene4-governance
5	Context Sidecar (killer feature)	NetSuite-native sidecar intelligence in AP workflows	context-sidecar + context-sidecar-highlight
6	NL Action Gate	Natural-language control with regex/LLM/allowlist gating	scene6-action-gate
7	Opportunity	SuiteApp.AI badge readiness, moat narrative, decision close	scene7-opportunity

The seven-scene sequence is what the storyboard-overview video navigates: reviewers can jump into any scene’s video to verify the claim-to-proof continuity. This is the operational implementation of “every claim maps to proof” — the scenes are the claims, the scene videos are the proof surfaces.

The four named differentiators

Per 01-executive-summary slide 2, differentiation rests on the combination of these four (each is its own module or feature). All four are now documented and all four are shipping per 04-technical-proof:

1. Golden Record MDM → mdm-central — v3.4.0, DB persistence (D1+D2+D3), survivorship rules
2. Context-Aware Sidecar → context-sidecar — v3.2.0, embedded mode, postMessage API
3. NL Action Gate → nl-action-gate — v3.3.0, 6 live actions, LLM intent parsing, regex fast-path + allowlist
4. Schema Drift Shield (formerly “Schema Drift Controls”) — v3.3.0, SHIPPING, with discovery, caching, drift detection + sync blocking (structured SCHEMA_DRIFT_BLOCKED result code per compliance-dashboard). Per 04-technical-proof Tier 3 — this is the first fully-documented version of the 4th differentiator.

The four enterprise safety mechanisms (architectural, per ai-governance-layer-video + 04-technical-proof)

Distinct from the four differentiators — these are architectural components that wrap every AI action:

Mechanism	What it does	Version
Reasoning Trace Engine	Logs justifications for every AI decision (DB-persisted)	Tier 2, shipped
Governance Pacer	Prevents throttling — respects NetSuite API concurrency limits (5 concurrent / 10 RPS per oracle-comparison)	v2.4.0, 3-tier rate limiting
DLP PII Shield	Redacts sensitive data — 10 regex patterns in DLPService.ts (ssn, creditCard, email, phoneUS, phoneIntl, medicalRecordNumber, accountNumber, ipAddress, apiKey, jwt) + GovernanceService.ts content-filter patterns. The compliance-dashboard snapshot shows 14 combined patterns; 11 confirmed in code, 3 (DOB, passport, driver’s license) not found as regex patterns and may be behind the live API or planned. See production-proof for the full reconciliation.	Tier 2, shipped
Approve-to-Apply	Cryptographic verification of human sign-off (hash verification)	v2.4.0, shipped

Open questions

• Which 12 modules are “core” and which 4 are “extension/platform”? Source 01 doesn’t say. Likely answered by ingesting 22-MODULE-LIBRARY.md.
• Is “NL Action Gate” the same as the “Natural Language Action Gate” mentioned in the Preston-Test README.md’s Embedded Intelligence section (“6/6 actions live + LLM intent fallback”)? Almost certainly yes — should be confirmed and merged on next relevant ingest.
• What does “Schema Drift Controls” actually do? Not described in this source.

Sources

• 01-executive-summary — claims 1, 3, 4, 5 (enterprise-integration-platform framing, 16 modules, differentiators, Squire Advisory naming)
• read-talking-points — claims 2, 3, 5, 6, 7 (AI integration governance layer framing, competitive thesis, six connectors, differentiation capabilities, Oracle/Celigo context)
• read-elevator-pitch — claims 4, 5, 8 (second-source “governance layer” framing, four-capability specificity, reasoning traces persisted architectural claim)
• ai-governance-layer-video — claims 1, 4, 5, 6, 7, 9, 10, 13, 14, 15, 16, 18, 20, 22, 27 (middle-intelligence-layer architecture, four named safety mechanisms, MCP bridge/gatekeeper, Oracle/OpenAI critiques, 75% cost reduction, competitive lead time, market window, SHA-256 delta sync, dual-ERP equal citizens, 12-core confirmation)
• narration-scripts — claims 1, 2, 18, 21 (seven-scene storyboard structure, Tier 1/Tier 2 evidence taxonomy, AI field mapping technique names, governance pacing + DLP differentiation via Oracle comparison)
• 22-module-library — claims 1, 2, 5 (definitive 12 core + 4 extension/platform module list, resolution of the long-running 12-vs-4 open question)
• 04-technical-proof — 4-tier feature inventory, 4 AI provider names with models, Schema Drift Shield v3.3.0 shipping, NL Action Gate v3.3.0 shipping, NetSuite sandbox TSTDRV2698307
• 26-canonical-metrics-and-wording — 6 named connectors, AI provider per-mapping costs, canonical wording guide, “avoid” list for outdated phrasings including the “6-12 month window” style tension
• oracle-comparison — NetSuite API concurrency limits (5 concurrent / 10 RPS), Oracle NSIP competitor naming, 8-row feature matrix