Technology

Models keep improving, and they still get your company wrong.Do not switch models. Give them accurate company knowledge.

Platty does not stitch together similar-looking pieces of code (RAG).

It analyzes the entire codebase to build a map. Documents outside the code are checked against the code, and only what holds up is kept.

PILLAR 01

Full static analysis engine

We break the entire repository down into files, modules, and systems, and connect them into a single graph.It works across languages and follows API calls, screens, and batch jobs.We decompose structure rather than search for similarity, so the same code always produces the same graph.Dynamic patterns that static analysis cannot connect are marked separately instead of hidden.

PILLAR 02

Requirements-engineering reverse translation

We summarize the graph from the bottom up and turn it into layers of business language: epics, business rules, and a glossary.The LLM is never asked to write freely. It only translates within the frame the structure defines.

PILLAR 03

Grading and Grounding (Grounding)

We check existing documents, terminology, and data schemas against the code graph and grade them as true, false, or unverified.Only what is verified goes into the SSOT. This is a system that audits documents, not one that trusts them.

PILLAR 04

Incremental updates

We detect commits and re-analyze only the affected parts. Every piece carries its source commit and freshness.You always know which version of the code an answer is based on.

Honesty mechanisms

A system that does not pretend to know

Enterprises got burned by AI becauseit acted like it knew when it did not.Platty is designed the other way around.

Confirmed and inferred

Every connection carries a source. Confirmed and inferred connections are never mixed

A connection confirmed by static analysis is proven by the structure of the code. You can trust it as is.When static analysis cannot make the connection and an LLM infers it, we mark that separately. Once a person verifies it, it is promoted to confirmed.Every answer shows whether its evidence is confirmed or inferred. Instead of claiming perfection, we draw an honest line between confirmed and inferred.

01

Evidence links

Every sentence in an answercarries its code evidence.

Q. What happens to data after a member closes their account?

Accounts are anonymized, not deleted.[1]

Source
40// Handle account deletion41export async function anonymizeUser(userId) {42await anonymize(userId);43return { success: true };44}
02

Evidence gaps stated

Every document carries a list of what could not be confirmed by evidence.Gaps are written down, not hidden.

Not verified1 item
The legal basis for the retention period could not be confirmed.

No evidence was found in the relevant laws, internal policy documents, or security guidelines.

03

Certainty boundaries

Where code alone cannot settle the matter, such as permissionsor exceptions, we mark the boundary and point to deeper evidence.

The code behavior is confirmed.

The code confirms that accounts are anonymized rather than deleted when a member closes their account.

Legal compliance requires a separate review.

Whether a data retention period is lawful, along with internal policy and exceptions, cannot be determined from code alone. Please check the relevant documents and legal counsel.

04

Freshness tracking

Every piece of evidence carries its source commit and freshness.A stale answer says it is stale.

account/anonymize.ts:42Base commit a81c9e2Up to date
account/anonymize.ts:42Base commit a81c9e2Change detected · needs recheck

Example answer · not real project data.

Won't this be unnecessaryonce models get better?

Models only get better at reasoning.They do not come to know your systems.

Even the most capable new hire cannot work without a handover. As models improve, the bottleneck moves to context.Platty does not compete with models. Whatever model you bring, Platty is the layer that makes it understand your company.