Atlas · Commercial
Technical Pre-Diligence
for Software Acquisitions
Run Atlas where the evidence lives.
Atlas runs locally against the software repository you are evaluating. Your source data stays in your environment. Knowlton does not need your repository uploaded to a cloud service in order to perform the analysis.
01 · How it works
Five steps, all of them local
- Install
- Acquire
- Analyze
- Generate
- Expand
Step 1
Install Atlas
Knowlton provides the Atlas runtime and the applicable acquisition entitlement — a signed grant your installation validates locally.
Step 2
Select the repository
You choose the repository to be acquired into analysis. It never leaves the machine you run Atlas on.
Step 3
Analyze locally
Atlas performs deterministic evidence analysis in your environment. Coverage and regeneration are verified as part of the run.
Step 4
Generate the outlook
You produce the evidence-backed Acquisition Evidence Screen — report, Knowledge Objects, and checksums — as local output.
Step 5
Expand when needed
Additional acquisitions, updates, and future capability packages are controlled by entitlement. What you already have keeps working regardless.
The customer workflow
Three commands
acquire — entitlement check, then analyze
status — consumption; never gated
render — rebuild a package; never gated
INSTALL → EXECUTE (local, offline-capable — never gated) → ACQUIRE REPOSITORY [entitlement checked here, and only here] → ANALYZE (local cognition over the acquired evidence) → GENERATE (ten-section report + Knowledge Objects) → EXPORT (your artifact, permanently yours) → NEXT ACQUISITION [new entitlement required — nothing else changes]
02 · The boundary
What stays with you, what Knowlton provides
What stays with you
- The source repository
- The evidence
- The analysis environment
- The generated results
- The exported report
- The Knowledge Objects
- The checksums
What Knowlton provides
- The Atlas runtime
- The applicable acquisition entitlement
- The Acquisition Lens
- The methodology
- Report generation
- Documented evidence and provenance
- Updates and support, per the applicable offer
03 · Entitlements
What the entitlement controls
Atlas entitlements govern the right to acquire a repository into analysis. They do not disable the software itself.
An entitlement governs
- Acquiring a repository into analysis
- Acquiring new capability packages
- Acquiring updates
- Support, where contractually applicable
When an entitlement expires
- Installed Atlas still runs
- Existing results still work
- Existing reports remain yours
- Acquired evidence stays usable
- Nothing is deleted or remotely disabled
- A new repository acquisition requires a new entitlement
No phone-home. No runtime DRM. The entitlement check happens at acquisition time, validated locally against a signed grant — that is the only place it happens.
04 · The deliverable
Before expensive technical due diligence
Full technical due diligence costs thousands to tens of thousands of dollars and takes weeks; the inexpensive screening services check financials and traffic, not engineering. The Acquisition Evidence Screen is the layer in between: a deterministic measurement of the target's engineering history that tells you whether — and where — to spend the expensive human phase.
Atlas does not tell you whether to buy the company. It tells you what the supplied engineering evidence supports and what human diligence should investigate next.
Current delivery target: three business days from receipt of the repository, for an operator-run engagement. Where you run Atlas yourself, the engine's own compute time is the only clock that applies.
Every screen is the same ten sections: executive evidence summary, observed history & activity, contributor and ownership concentration, change concentration, recent activity, history completeness and origin, evidence gaps and not-established items, questions for human diligence, provenance summary, and the method & limitations statement. Delivered as PDF, Markdown, and HTML, with machine-readable Knowledge Object JSON files, a MANIFEST.sha256 covering every file and the input identity, and an engagement record. The raw Event Log, run logs, and source code are never included.
The sample below is genuine output: a complete screen of a real 4,349-commit open-source SaaS repository, with full provenance and verified byte-identical reruns. Excerpted; the full sample is available on request.
Acquisition Outlook — established answers
- DM 4,349 commit(s) over 2,536.9 day(s): 1.71 commits/day. — 4,349 source events
- DM Top author made 1,116 of 4,349 commit(s) (26%). — identity-method caveat stated in report
- DM 144 of 4,349 observed commit(s) fall in the final 90 days of observed history.
- DM Observed history reaches 1 root commit(s); no truncation boundary recorded.
- DM Most-changed file identified, with exact change counts.
Not established
- UNK Everything code-content: languages, dependencies, licenses, tests, security — outside this lens's evidence by design.
- UNK Anything predictive: this outlook states observed history only.
Questions for human diligence
- REC Investigate key-person dependency: who maintains the hotspot, maintainer retention, bus factor beyond the top identity, contractor IP assignment.
Determinism: two full passes byte-identical (verified on this run) · engine compute for the full 4,349-commit history: 67.4 minutes · no AI provider involved at any step.
05 · Pricing
Priced by acquisition
One acquisition means one repository brought into analysis, producing one screen. What you generate from it is permanently yours.
Founding Screen
$1,500
- One contracted repository acquisition
- Full ten-section Evidence Screen
- Builder-direct support and a feedback call
- Objective refund conditions
Standard
$2,500
- One contracted repository acquisition
- Full ten-section Evidence Screen
- PDF + Markdown + HTML, Knowledge Objects, checksums
- 3-business-day target once intake is validated
Professional
$25,000 / year
- Repeated acquisitions under the documented fair-use and license terms
- Updates and priority support
- White-label output for client engagements
- Firm-run local Atlas as distribution opens PLANNED
Fair-use limits on the professional license are contractual, not technical — there is no telemetry, and no metering beyond the acquisition-time grant check. Large repositories (over 10,000 commits or 1 GB) are individually quoted after a size check.
06 · Delivery status
Current V1 Delivery
The first commercial engagements are currently supported through Knowlton's operator-run delivery workflow while the customer-distributed Atlas package completes its final distribution and licensing requirements.
Mode A · available now
Operator-run delivery
Knowlton performs the acquisition on your behalf on a dedicated, hardened engagement machine. You supply the repository as a git bundle through your own secure share, or a short-lived read-only URL you revoke after transfer; we run the pinned pipeline and deliver the package.
Under this mode — and only this mode — the repository is transferred to us. That transfer is contracted, temporary, and covered by a scheduled deletion policy 7 days after acceptance. Security posture →
Mode B · the product
Customer-run local Atlas FINAL DISTRIBUTION REQUIREMENTS PENDING
The single-binary customer product is built and verified: 9 of 9 tests passing, and a full customer-mode dry run completed with coverage verification and independent double-run byte-identical regeneration both passing. The entitlement grant is validated offline against a signed key; a spent grant exits with an honest message and changes nothing else.
It is not yet sold: distribution awaits counsel-drafted license text, production signing keys replacing the demo key, and founder ratification of the no-runtime-DRM posture. Those are paperwork and key-management gates, not engineering ones.
Both modes produce the identical deliverable from the identical pinned engine and lens. The difference is whose machine runs it.
07 · Limits
What this is not
Said before you ask:
- Not full technical due diligence. It is the evidence layer that tells you whether and where to spend on it.
- Not a security audit. No vulnerability analysis of any kind.
- Not legal analysis. No license or IP conclusions.
- Not financial diligence. Nothing here reads revenue.
- Not a code-quality judgment. Git metadata alone cannot establish one — so we don't.
Current scope limits, stated plainly: Git repositories only, one per acquisition; Git-metadata evidence only; a single-maximum change hotspot with whole-history aggregates and one 90-day recency window; author identity as name-and-email pairs, unmerged, with the caveat carried in every report.
Every screen carries its limitations statement verbatim, with the engine and lens versions, the input hash, and the coverage-verification result. The report informs your diligence; it is not professional technical, legal, security, or investment advice.