Ansatz — Public Diligence

I take technical ownership of a specific problem in your research or investment process and deliver a concrete result.

Usually, that means delivering something like:

• a working internal tool
• an integration or automation
• a more reliable research workflow
• a dependable prototype or first capability
• a monitoring or data system

Before we start, we agree on what I’m delivering, what it needs to do, what I need from you, and how we’ll know it’s done.

Sometimes the right first result is not software. For a sufficiently uncertain problem, it might be a feasibility answer, design, diagnosis, or decision that materially reduces uncertainty. If so, that is explicit up front.

Ansatz is most useful when valuable work sits between understanding an investment process and taking technical ownership of it.

That can include research, data, automation, monitoring, reconciliation, integrations, and adjacent investment-operations workflows.

You do not need to arrive with a software specification. Bring the workflow, objective, or constraint.

If you already have a trusted internal engineer who understands the investment context, has the mandate, and has time to do the work well, using that person may be the better answer.

There are four main engagement shapes.

First sprint

The usual starting point is a bounded first sprint: generally $5–10k over roughly two weeks.

The sprint has:

• one useful agreed result
• a fixed price set before work begins
• explicit acceptance criteria
• known dependencies and access requirements
• an agreed level of robustness, validation, and handoff

Payment is normally 100% upfront.

After delivery, the client generally has five business days to identify a specific unmet acceptance criterion. I get a reasonable opportunity to fix an actual miss.

If I materially mis-scope a fixed-price sprint, cannot deliver the agreed result, and we do not agree that the work produced a useful standalone result instead, my default commercial position is a full refund. Exact terms belong in the engagement agreement.

The purchase is the agreed result—not a guaranteed investment, P&L, or business outcome.

Larger bounded project

A larger project makes sense when the end state is clear enough that execution is the main risk.

These can use:

• an upfront deposit
• milestone payments
• milestone acceptance where useful
• explicit lightweight change control
• final integrated acceptance

If the project ends early, the unwind should fairly reflect completed work, earned value, unearned payments, and genuinely reserved near-term capacity.

Fractional ownership

Fractional work means ongoing ownership of a defined research-systems or technical domain.

That can include an evolving backlog, architecture, integrations, maintenance, debugging, vendor judgment, and proactively noticing problems.

It is not a bucket of hours or an unlimited promise to handle anything technical.

My current default is:

• an initial three-month commitment
• payment monthly in advance
• month-to-month after that
• 30 days’ notice

Large one-off projects can still be scoped separately.

Managed operation

Keeping a system running is different from building it or owning its technical evolution.

Monitoring, incidents, response expectations, continuity, and availability require a different agreement and risk model.

Managed operation is therefore selective and separately agreed. A delivered system does not quietly become an implied 24/7 support obligation.

No surprise overages.

If a material condition changes, I surface it, and we decide what to do:

• trade scope
• change timing
• add budget
• produce a smaller useful result
• pause
• stop

I distinguish between a client changing the requirement, an agreed dependency failing, genuinely unforeseeable conditions, and something I reasonably should have caught during scoping.

Those do not all allocate responsibility the same way.

Acceptance also does not reopen scope. Wanting a different result after seeing the agreed one is a change request, not failed acceptance.

Usually:

• enough context to understand why the result matters
• the minimum access needed to do the work
• timely correction when I misunderstand something
• decisions only the client can make
• a clear person with authority to accept the result

Some engagements also require security, procurement, platform, or deployment approval.

You should not need to project-manage me.

If several internal groups have legitimate authority over the work, we identify who owns which decisions. If missing authority or cooperation makes delivery impossible, I surface that problem rather than spending the engagement indefinitely mediating the organization.

The client owns the client-specific work product it paid to have created.

Ansatz retains pre-existing IP and general reusable capability.

If retained Ansatz IP is necessary to use, modify, maintain, or hand off the client's result, the client receives sufficiently broad and durable rights to do that.

Your confidential material does not become reusable Ansatz IP. That includes:

• positions and trades
• investment theses
• models and signals
• proprietary research
• client-specific code
• distinctive workflows and methodology

Material third-party and open-source dependencies remain subject to their own terms.

Broader ownership or exclusivity can be negotiated when necessary, but it is a different purchase.

That is the default design goal unless you deliberately choose an ongoing managed or fractional relationship.

Depending on the system, handoff can include:

• source and repository access
• client-controlled credentials
• reproducible setup
• deployment and configuration information
• architecture and operating notes
• known assumptions and limitations
• rights needed to continue operating the system

Documentation should match the intended use. A prototype and a consequential production system do not need the same artifact set.

Ansatz is principal-led, but the work should not depend unnecessarily on my personal accounts, undocumented knowledge, or inaccessible infrastructure.

The engagement states what correction and support are included.

An original defect is different from:

• a new requirement
• an environment change
• a changed dependency
• a new intended use
• ordinary future maintenance

There is no universal public correction-window guarantee and no perpetual implied maintenance obligation.

A sprint can end cleanly, lead to another project, or become a fractional relationship. Neither side is required to continue.

I do not intentionally create technical lock-in to force follow-on work.

Yes. AI-assisted and agentic development are part of how I work.

I remain accountable for everything Ansatz delivers.

For confidential client information:

• material AI providers and uses are disclosed
• the categories of confidential information exposed are made clear
• the client can veto that exposure before it happens
• stricter engagements can use an explicit provider allowlist

Convenience is not permission to send client information to a model.

If the client does not permit any workable AI-assisted development environment, the engagement may not be a fit.

The standard is not “a human typed every line.” The standard is knowing whether the result is fit for what it will be trusted to do.

Depending on the consequences, validation may include:

• automated, integration, and static checks
• representative cases and invariants
• targeted human review
• source and provenance checks
• reproducible calculations
• staged deployment
• explicit review of high-consequence assumptions

For research work, I care especially about whether sources are real and correctly represented, calculations reproduce, conclusions are supported, and assumptions are visible.

For market data, important issues can include point-in-time availability, revisions, survivorship, stale fields, units, mappings, corporate actions, and vendor semantics.

I prefer an explicit invalid or unknown result to a plausible-looking silent failure.

I do not reuse one client's proprietary information for another client.

That includes distinctive client know-how remembered after the original files are gone. General engineering knowledge and generic professional learning remain reusable; client-specific substance does not.

I also try to avoid unnecessary exposure to:

• MNPI
• planned trades
• sensitive positions
• activist plans
• proprietary investment conclusions

Sanitized examples, historical cases, and substitute data are preferable when they can solve the problem.

No client name, logo, engagement, screenshot, testimonial, or case study is made public without explicit permission.

I do not personally trade on material client-confidential, security-specific investment substance that could reasonably influence my own trading.

That includes proprietary theses, signals, model outputs, confidential research conclusions, and intended trades or positions—not only literal MNPI.

Serving firms that overlap in markets, securities, or strategies is not automatically a conflict.

If two mandates become so close in proprietary methodology, objective, or timing that credible separation is doubtful, I surface the issue and either establish an acceptable boundary or decline the conflicting work.

I also do not accept undisclosed referral fees, reseller margins, or similar incentives that could secretly bias a technology recommendation.

The operating principles are:

• minimum necessary access
• least privilege
• scoped and revocable credentials
• client-controlled repositories and infrastructure where practical
• read-only or non-production access where sufficient
• normal client review and deployment controls

I minimize confidential working copies and prefer client-controlled systems where practical.

My working retention target for confidential working material is around 30 days after acceptance, subject to ongoing work or support, agreed client requirements, and practical retention constraints.

If an engagement requires specific security controls, provider configurations, retention rules, or access restrictions, we agree on them before the relevant information or systems are exposed.

If a credible incident affects client systems or information, I contain it, revoke or rotate affected access where appropriate, preserve relevant evidence, notify the client promptly, explain what is known and uncertain, and cooperate in remediation.

Ansatz is principal-led by default.

No human subcontractor will materially work on an engagement or receive confidential client information without disclosure first.

If outside help is appropriate, the person's role and access are explicit, equivalent confidentiality and handling obligations apply, and accountability remains with Ansatz.

Yes, when the requirements are proportionate to the engagement.

I am comfortable with relevant diligence questions, reasonable questionnaires, serious client paper, and demonstrations of controls or evidence where appropriate.

A small sprint does not implicitly include unlimited device or account access, arbitrary audit rights, client-directed penetration testing, or weeks of bespoke compliance documentation.

If procurement becomes materially larger than the underlying engagement, we should redesign the arrangement, scope that work separately, or decide that the fit is poor.

I take responsibility for agreed work, but a small systems engagement should not silently become unlimited exposure to downstream trading or investment losses.

My normal position is that liability should be proportionate to the scope, economics, and control of the engagement, with indirect or consequential damages excluded where appropriate.

Sensitive confidentiality, security, or IP obligations may justify different treatment.

Exact terms belong in the contract.

Ansatz currently provides investment research systems and related technical ownership.

That can include building, debugging, validating, and explaining models or signals and interpreting them for system or research-workflow purposes.

It does not currently include:

• portfolio management
• directing specific trades
• position sizing
• portfolio allocation authority
• standalone securities recommendations as a service

If a real engagement moves materially toward security-specific investment advice rather than systems work, I treat that as a separate boundary question before proceeding.

The promise is the agreed result and the standard appropriate to its intended use.

A first sprint is not automatically a polished institution-wide production platform. It might instead be a narrow reliable capability, operational internal tool, dependable prototype, or consequential feasibility answer.

The intended use determines the required engineering rigor, validation, documentation, deployment, and support.

I do not promise:

• error-free software
• future investment performance
• business ROI
• uninterrupted future availability
• permanent dependency versions
• identical stochastic model outputs
• guaranteed third-party data correctness
• 24/7 support unless specifically purchased

What I can make explicit is what I am taking responsibility for, how we will know whether I delivered it, what assumptions that promise depends on, and what happens if those assumptions change.

Send me a real workflow, system, or technical problem you want improved.

I’ll return a short proposed approach: what I think the problem is, why it matters, how I’d approach it, and what a sensible first sprint could accomplish.

If it resonates, we scope the sprint and get to work.

matt@ansatz.sh →