Turgon × Neon
A Working Point of View.
How we'd approach credit explainability, fraud, and collections — on one governed foundation, inside your AWS.
Introduction.
This document follows our conversation with Thiago and lays out how Turgon would approach the three areas you identified — credit-decision explainability, fraud, and collections — on a single governed foundation, running inside your AWS environment.
It deliberately mixes what we believe with what we still need to learn. Facts you shared with us are stated plainly and marked Confirmed; anything we inferred is marked Hypothesis and paired with an open question.
This is written to be discussed, not accepted — tell us where we're wrong.
Who we are.
Turgon is an AI-native systems integrator based in San Francisco. We deploy multi-agent systems inside our clients' own cloud environments to map, catalog, and modernize complex data estates — work that historically took integrator teams quarters, delivered in weeks, with a human approving every step.
Our agents build an ontology of your environment first, so everything they produce is grounded in how your data actually connects. That ontology, plus mandatory human validation, is how we control hallucination in settings where "mostly right" is not acceptable.
We've done this inside Fortune 500 environments — Western Digital and First Student. Details in Track Record.
Not a black box
Every step our agents take is inspectable, versioned, and produced against an ontology you can audit.
Not a SaaS you ship data to
Our agents deploy inside your cloud environment. Your data does not leave your perimeter.
Not a replacement for your team
A human on your side approves every step. What we build runs in your environment and belongs to you.
Everything we build runs in your environment and belongs to you.
What we heard from you.
Our understanding from our conversation — correct anything we got wrong.
You're rebuilding your data foundation from scratch, domain-driven — every data product (databases, models, dashboards) domain-owned.
You're building your ML platform rather than buying one, scaling from dozens of models toward hundreds.
You consume infrastructure as a service, not a platform — your dbt boilerplate keeps analysts out of consoles, and you deliberately control technology lock-in.
You operate under BACEN oversight: any credit decision must be explainable, on demand, completely.
Your credit decisions are deterministic by design — rules plus traditional ML — and you're rightly skeptical of probabilistic systems anywhere near them.
Fraud runs on hard rules and is owned outside the data platform team.
What did we get wrong, and what's missing from this picture?
How we'd approach your three use cases.
These are the three areas you identified. For each: what we understood, how we'd approach it, the guardrail that keeps it safe, and what we'd need to learn from you first.
Credit-decision explainability.
When BACEN or a customer asks why a credit decision was made, assembling the complete answer is a manual effort across systems.
An agent assembles the full evidence chain on demand — policy version, variables, model inputs, data lineage — as an auditable package.
AI explains decisions; it never makes them. Your deterministic engine remains the sole decision-maker.
What does assembling a BACEN response take today — people, days, systems touched?
Fraud.
Your fraud engine runs on hundreds of hard-rule metrics and sits outside the data platform team.
Our hypothesis, labeled as one: graph-based entity linkage — shared devices, accounts, counterparties — could be computed as features feeding your existing rules engine. Your rules stay in charge; the graph widens what they can see.
The rules engine remains the decision surface. Ownership stays with the team that owns it.
Do your fraud analysts ever want linkage the rules can't express today?
How would the team that owns the engine want to engage?
Collections.
Your funnel here is narrower and shaped by default timing. This is where we have the most to learn, so we lead with questions rather than an approach.
Possible direction: unifying payment, contact, and credit-context signals into one grounded, explainable prioritization view.
No prioritization ships until the signals are grounded in your data and explainable to the operator acting on them.
What data decides who you pursue, when, and how — and where does that process strain?
| — | Credit Explainability | Fraud | Collections |
|---|---|---|---|
| Scope | Assemble the complete evidence chain behind any credit decision, on demand. | Add graph-based entity linkage as features into your existing rules engine. | Unify payment, contact, and credit-context signals into one prioritization view. |
| What we'd need from you | Access to policy versions, model registry, decision logs, and lineage sources. | A working session with the fraud team to understand what rules cannot express. | A walkthrough of the current funnel, data sources, and where it strains. |
| What you'd get | An auditable package per decision — reproducible, versioned, BACEN-ready. | A feature service your rules can call; linkage the rules can act on. | A grounded, explainable prioritization view — direction depends on what we learn. |
| Duration | Weeks, measurable start. | Weeks, feature-scoped pilot. | Discovery first, then scope. |
| The decision it informs | How you answer regulators and customers. | What your fraud engine can see. | Who you pursue, when, and how. |
All three run on the same foundation — described next — so choosing one doesn't foreclose the others.
How it works — inside your VPC.
An agent runs on an EC2 instance inside your VPC. It connects via APIs and reads metadata — minimum-necessary access, scoped and revocable. From that it builds a data dictionary plus a "constitution": the rules, boundaries, and governance it must operate within.
On that base it constructs an ontology of your environment — the map of how your domains, systems, and definitions actually connect. Every artifact it produces — a mapping, a catalog entry, a transform, a definition — passes a human approval gate before it counts.
All code is dbt, SQL, and Python — readable, owned by you, still yours if we never speak again. LLM-agnostic: we can run on your licensed enterprise model if compliance prefers it.
Unchanged.
Operational systems, files, APIs, warehouses. We do not touch them.
Config-driven ingestion.
In-pipeline data-quality gates, dbt + Python transforms, single orchestration plane.
Bronze / Silver / Gold.
Bronze immutable raw · Silver conformed, DQ-gated, PII-tagged, glossary-enforced · Gold domain marts, aligned to your Snowflake path.
Automated dictionary + ontology.
Glossary enforced in code, column-level lineage, human gates on every artifact.
Retained.
Your BI, notebooks, apps, and ML platform continue to consume from Gold.
Draft the artifact — mapping, transform, catalog entry, definition.
Adversarially test the draft against the constitution and ontology.
A person on your side approves. Signed to version control.
Only signed artifacts count. Nothing promotes without a signature.
Where does this picture diverge from the platform you're building?
Our operating principles.
Agents come to your data.
They run inside your AWS. Nothing egresses.
Open, license-free core.
dbt, SQL, Python. No proprietary runtime to inherit.
Human-in-the-loop is mandatory.
Every agent output requires explicit sign-off, recorded in version control.
Agents never decide.
Your deterministic rules and models make decisions; agents retrieve, assemble, document, and flag with confidence estimates.
Ontology as durable memory.
Your domains and definitions captured as executable infrastructure, not documentation that rots.
You own the code.
Every artifact remains yours. Managed service is a choice, never a dependency.
Your LLM if you prefer.
Enterprise model restrictions are supported, not tolerated.
Prove small, against your bar.
Value demonstrated on one domain, measured against acceptance criteria you define, before anything scales.
Determinism & governance.
A short, direct section. This is the question a regulated lender should ask first, so we answer it first.
Agents never make credit decisions.
Decisions remain deterministic.
Every action is auditable.
Auditable, human-signed evidence. Every action logged. Every anomaly flagged with a confidence estimate and routed to a person.
Executed at runtime — business definitions enforced inside silver transforms, lineage generated by the pipeline itself. Not stored as documents nobody maintains.
Security & compliance.
Answers before you ask — our standing security posture, available for your vendor review today.
ISO 27001, independently certified.
- ▸ISO 27001 certified — independently certified ISMS.
- ▸Incident response aligned to NIST SP 800-61 Rev. 2.
- ▸Quarterly penetration testing with documented results.
- ▸Formal vulnerability management with documented remediation SLAs.
Encrypted, scoped, revocable.
- ▸AES-256 at rest.
- ▸TLS 1.2+ enforced in transit.
- ▸Your data belongs to you — access scoped, logged, revocable.
- ▸Minimum-necessary data access per workstream.
Read-only agents, zero training on your data.
- ▸Zero customer data shared with public LLMs or used for model training — contractually prohibited under enterprise AI provider agreements (zero training, zero retention after processing).
- ▸Agents are read-only with human-in-the-loop — no autonomous actions against your systems.
- ▸Full audit trail on every agent action (LangSmith tracing + Helicone LLM monitoring).
- ▸Low-confidence outputs routed to human review.
- ▸You may require your own enterprise AI accounts or restrict vendors.
MFA, PAM, RBAC, SSO.
- ▸MFA enforced across all internal systems — no exceptions.
- ▸Privileged access management (AWS Secrets Manager + 1Password).
- ▸Quarterly access reviews with documented on/offboarding.
- ▸RBAC with least privilege and strict customer-data segregation — no cross-customer access.
- ▸Enterprise SSO via SAML, OIDC, SCIM.
| Log type | Standard retention | During incidents |
|---|---|---|
| Application / API logs | 90 days | 3 years during incidents |
| Auth / access logs | 1 year | 3 years during incidents |
| Security events | 1 year | 3 years during incidents |
Documented BCP + DRP, redundant AI providers.
- ▸Documented Business Continuity Plan and Disaster Recovery Plan.
- ▸App / data / storage tier segregation.
- ▸Dual LLM provider redundancy (OpenAI + Anthropic).
- ▸SBOM maintained and available.
Active coverage through 03/2027.
- ▸General Liability — $1M per occurrence / $2M aggregate.
- ▸Tech E&O — $2M aggregate.
On engagement completion or written request, all your data and derived artifacts are permanently deleted, written confirmation is provided, and all credentials are returned or revoked.
Proving it — a small, measurable start.
We'd rather show you than tell you. The proposal: an ontology + enriched catalog over one domain of your choosing, on your existing S3 / Trino lake, running in your AWS. Roughly 1–2 weeks once access is granted. Everything produced is yours.
You define the acceptance bar.
Your engineers set the accuracy and parity criteria before we start. The result is judged against your bar, not our claims.
Validation slice
One domain of your choosing, on your existing S3/Trino lake, in your AWS.
Foundation
Ontology + catalog across priority domains as you move toward Snowflake.
Your chosen use case
Credit explainability, fraud, or collections — the one that clears your bar first.
Ongoing operation
By choice. Your code, your environment, your call.
What we still need to learn.
A partner who claims to have no questions isn't paying attention. Here's what we'd want to understand before proposing anything firm.
What did we get wrong, and what's missing from the picture of how you work?
Where does our architecture diverge from the platform you're building?
Is there a preferred or licensed LLM we should plan around?
What does assembling a BACEN response take today — people, days, systems touched?
What would a satisfying answer look like for you and for the regulator?
Do your fraud analysts ever want linkage the rules can't express today?
Who owns the fraud engine, and how would that team want to engage?
What data decides who you pursue, when, and how?
Where does that process strain — and what would you want to be different?
What does your security review require of us?
How would you want a POC's success measured?
Who on your side would own the acceptance bar?
Western Digital — at scale, in their AWS.
Western Digital.
Regulated-grade auditability at scale, in the customer's environment — and the same client cleared us through their Fortune 500 vendor security assessment.
Where this goes.
Pick one use case. We prove it small, against your bar, in your environment.You decide from evidence.
Which of these, if it worked, would be most worth your CTO's attention?