Understand
Find out what the system actually does.
Inherited, acquired, or built by people who have moved on. Foundry maps how a system behaves, what it exposes and what it depends on, and tells you how sure each finding is.
Tell us about your system- VerifiedCalls
billing-apiPOST /charges before the order is confirmed - VerifiedEmits
order.createdEvent on the message bus - VerifiedReads
inventory-dbDirect SQL, bypasses the inventory serviceNot in docs - ObservedReads
pricing-rules.csvFrom a shared drive, reloaded hourlyNot in docs - ObservedRun by
reconcile.shNightly cron re-posts failed ordersNot in docs - InferredConsumed by
3 servicesListeners on order.created; one is unidentifiedNot in docs - OpenWrites
orders_archiveTable written on every order. Reader unknownNot in docs
You recognize this when.
The documentation describes a different version.
The system kept evolving after the last person wrote it down. The code is now the only accurate description, and nobody has read all of it.
Every change starts with an investigation.
Engineers spend days establishing what a module does before touching it. The next engineer does it again.
You are about to depend on it more.
A migration, an integration or an agent is about to lean on behavior nobody has confirmed.
What you end up with.
Artifacts your engineers can use the same day. Each finding carries its evidence state. How we work.
Map undocumented systems
Find out how software nobody fully documented actually behaves: its interfaces, dependencies and hidden rules.
Delivered as: Behavior report · dependency map
Reconstruct APIs
Rebuild an accurate interface specification from how a system really responds, not from what the docs claim.
Delivered as: OpenAPI specification
Verify behavior
Repeatable tests confirm each finding. Anything not tested is labeled as observed, inferred or open.
Delivered as: Test suite · verification results
Who usually asks.
Engineering leaders
Make critical engineering decisions with fewer unknowns.
Engineers
Understand the behavior before you rebuild the interface.
Read more.
How to build an inventory of undocumented dependencies
A method for finding what a system calls, reads, writes and waits on, when nobody wrote it down, and for recording how sure you are about each item.
How to define an effective software intelligence engagement
What to pin down before anyone analyzes a system for you: the decision, the authorized target, data handling, success criteria, deliverables and limits.
How to investigate an undocumented system without confusing inference with fact
A working method for learning what an undocumented system does, and for keeping what you saw separate from what you assumed.
How to measure the cost of repeated engineering investigation
A method for counting the time engineers spend re-learning how a system works, so the cost of undocumented behavior can be compared with the cost of fixing it.
What a useful software behavior report should contain
The sections, evidence labels and level of detail that make a behavior report usable by engineers, not just readable by managers.