CASE STUDY · POINT FIELD PARTNERS
advisory for a private-equity family office: what to build, what to buy, and what to prove first.
point field partners is a private-equity family office. i advise its team and portfolio on AI architecture, build versus buy, and vendor choices, outside marketing entirely. this page covers the decisions and one checkable proof of feasibility.
advisory work, plus one proof pending client review
the proof figures are my own report of phase one. the client has not yet confirmed them. no savings, adoption, or valuation figures exist.
Apr 2026
first scoping work with the investment team. the engagement is active today
3
source portals collected into a client-controlled SharePoint with checksum proof, pending client review
7
step validation workflow defined for phase one
1
folder the automation can write to. no tenant-wide permissions
what this engagement is
this engagement sits outside marketing. point field partners is a family office that invests in operating companies. it asked for help with AI and data architecture.
my role is advisory. i supply judgment, architecture, and build-versus-buy calls across what the firm's team and its portfolio companies send me.
that is why this page exists. my work is wider than marketing, and this is the clearest evidence.
the mandate came in three layers
the first layer was a wish list for the firm's own team. a document review tool, a searchable repository across email, files, and the deal system, a scheduling assistant, meeting prep, sourcing, and filtered news.
the second layer was a one-off question from a portfolio company. how should it think about data retention when it uses an enterprise AI plan.
the third layer was the flagship. a portfolio operating company needed a structured way to price assets from several external data sources.
my first move on all three was triage. what can be built now. what can be built with constraints. what depends on third-party access that nobody controls.
decisions i made, and why
the advisory value sits in the calls. here are the ones on record.
sourcing tool. i advised against a custom build. an existing enrichment platform already covers the data sources and writes back to the deal system through its API. that is a two to three week engagement and it leaves no software to maintain.
contract review. i diagnosed a C-grade result from an off-the-shelf legal skill as a prompt engineering gap. the fix is ten to fifteen examples of outside counsel's markups. my estimate was a B-plus to A-minus.
deal review. a Claude skill plus a curated folder of past deal summaries. the first input is a thirty to forty-five minute session to design the template.
data residency. i laid out two architectures. build on the model API so the company owns its data. or run open-weight models on its own hardware. i also asked why only one model vendor was under consideration.
slide generation. AI-made slides come out structurally correct and visually mediocre. i said so in writing and recommended a human design pass.
phasing. the client narrowed phase one to a single question. can the data sources be retrieved and landed in the reporting tool. i committed to a short written summary with a clear go or no-go on each source before any build starts.
the proof asset. external market data is available to every competitor. the company's own transaction history is the one input a competitor cannot buy. so the design starts from the portfolio company's own data.
one technique. i did not want five different ways to pull data from five sources. i chose one repeatable acquisition approach for the sources without an API.
raw first. the portal download screen cannot select output columns. i recommended keeping the complete raw file and applying the approved field selection after download. the client's operations lead asked for per-category folders and header validation before any overwrite.
least privilege. when a broad connector needed tenant admin approval, i narrowed the request. one single-purpose application, write permission on one existing folder, and certificate authentication.
phase one: a feasibility proof, pending review
phase one asked a narrow question and produced an auditable answer. most of the source portals have no API and need an authenticated session.
Ascend built a collection workflow for three of the portals. it retrieves the file, validates it without changing a single source row. it uploads the raw file and a manifest to the client's SharePoint, downloads both again, and confirms that file size and SHA-256 match.
each destination folder holds exactly two files. the raw file and a manifest.json. anyone with the file can recompute the hash and check the claim without trusting me.
the validation workflow has seven steps. approve the exact report and filters. confirm the permitted retrieval method. capture the raw file. validate the filename, byte size, headers, row count, required fields, and checksum, then write a run manifest. land the artifact in the approved folder. read the destination back independently. rate each source yes, maybe, or no for phase two.
i sent an acceptance packet on october 24, 2026. it holds a workflow diagram, a contract-to-evidence map, run receipts, verification instructions, and the work deferred to later phases. on october 26 i opened a hosted evidence room for the client's technical reviewers and asked for a verdict.
as of october 27, 2026 the review is pending. this page reflects the status on that date.
the limits i wrote down myself
the acceptance packet states what it does not claim. ten-cycle production acceptance, a complete portal catalog, production alerting, and the remaining hardening work are not claimed.
production authentication handling is unresolved. that gap is named in the evidence room.
i prefer to be disproved by a reviewer than believed by a reader. a feasibility proof that overstates itself is a liability for the next phase.
what i can and cannot claim
i can claim the advisory judgment and the written recommendations. they are in email and in proposals, with the reasoning attached.
i can claim a checkable phase one proof for three portals, pending client review. the client's reviewers hold the evidence and the verification steps.
i cannot claim a delivered valuation tool. i cannot claim savings, time saved, or adoption. none are recorded, and later phases have not started.
the firm, its team, and its portfolio companies are the source of truth on this engagement. i name only the firm here.
point field partners questions.
is this marketing work?
no. it is advisory on AI architecture, data infrastructure, and build-versus-buy decisions for a private-equity family office and its portfolio. it shows the range of work behind my marketing practice.
did you deliver a used-equipment valuation tool?
no. phase one is a feasibility proof that authenticated sources can be collected into the client's SharePoint with checksum evidence. the valuation work comes later, if the client approves it.
what can i check for myself?
the client's reviewers hold the evidence and can recompute the file hashes. i cannot publish the collected data. a reference conversation with the firm needs its permission, which i will request if you ask.
why name the firm but not its people or portfolio?
the work involves confidential deal activity and portfolio company data. the page names the firm and nothing else.
let's name the first blocker worth fixing.
Thirty minutes to name the constraint and the first useful fix.
book a repair working session →