Briana Halim · AI Transformation Owner, Product & Design

Discover. Reimagine. Build.

I turn complex business workflows into working AI solutions: mapping the operation, designing the system, building with AI-assisted tools, and testing how it handles uncertainty.

Selected work

System architecture & execution.

Cannabis Acquisition Intelligence

Multi-source acquisition intelligence linking licenses, ownership, zoning, and GIS clusters for portfolio-level planning.

Originally built for Haven on June 1, 2026; separate company engagement followed.

View full project
Problem
An operator judging licensed retail sites one at a time. What actually decides a site is what surrounds it — the licenses, operators and zoning nearby — and that sits across separate public sources that don't talk to each other.
Stayed human
Every acquisition decision, every offer.
What I built
A multi-source system connecting licenses, entities, operators, owners, zoning and property data, with GIS cluster mapping that pre-groups viable locations — so a site is judged by whether the surrounding locations support the retail model. That moved the product from location search to portfolio-level acquisition planning.
How I tested
Reviewed cluster outputs against the operator's own knowledge of the market and corrected the grouping rules wherever the two disagreed.
Status
Originally built for Haven on June 1, 2026. A later Upwork engagement concerns work for his company and is separate from the original build.
System architecture
Connect license, entity, operator, owner, zoning, and property records into one acquisition workflow. GIS grouping adds the surrounding network to each site’s assessment, so the operator can review a location in its commercial context.
Hard problem
A licensed location is only one part of an acquisition decision. The surrounding operators, locations, and zoning change whether that site supports the retail model. The system must connect these relationships before the operator evaluates the opportunity.
My contribution
I expanded the brief from individual property search into network acquisition planning, designed the grouping logic, and refined it against the operator’s market knowledge. The original system was built for Haven; subsequent company work is a separate engagement.

How the system works

Step 1

Connect the records around a location.

A property decision depends on more than an address. The workflow brings together the surrounding license, operator, ownership, and location context.

01 / SOURCE RELATIONSHIPS

Licensed operation
License ↔ entity ↔ operator
Property context
Location ↔ owner ↔ zoning context
Review question
Do these records support this opportunity?

Architecture overview of the original system for Haven; not a map of live opportunities.

Step 2

Evaluate a network, not an isolated pin.

GIS grouping adds the relationship between nearby locations to the acquisition review. The operator can judge how surrounding sites support the retail model.

02 / SPATIAL GROUPING

Individual location
Candidate site and supporting records
Surrounding network
Nearby licenses, operators, and properties
Grouping rules
Refined against operator market knowledge

Illustrates the decision structure. Geographic and regulatory facts require source review.

Step 3

Keep acquisition judgment with the operator.

I expanded the original property-search brief into portfolio-level acquisition planning. The original build for Haven and the later company engagement are separate.

03 / HUMAN DECISION

Original build
For Haven · June 1, 2026
Review output
Locations and their network context
Final authority
Operator approves acquisitions and offers

Later Upwork work for Haven is a separate engagement.

Foreclosure Acquisition Intelligence

A rules-driven acquisition pipeline with evidence receipts, freshness controls, explainable scoring, and CRM review routing.

1,200+ filings processed; in use by one operator.

View full project
Problem
An acquisition process held together by a buyer's memory of which counties, filings and signals matter, and in what order — against a filing stream that never stops arriving.
Stayed human
Every acquisition decision, every offer, every valuation. The system narrows the review queue and shows the supporting evidence; it does not recommend a buy.
What I built
A pipeline over public foreclosure filings in Orange and Riverside County: qualification rules, scoring, reason codes and evidence receipts on every candidate, freshness and confidence controls so stale or thin records say so, PASS / FAIL / REVIEW routing, and a CRM review queue the operator works from.
How I tested
1,200+ public foreclosure filings processed and checked against the source records; where a routing decision didn't match the record I corrected the qualification rule rather than the output.
System architecture
Public filings from Orange and Riverside counties flow through qualification rules, scoring, and reason codes. Evidence receipts, freshness, and confidence controls accompany the candidate into a PASS / FAIL / REVIEW state and the operator’s CRM queue.
Hard problem
High-volume filtering is useful only if the operator can see why a record advanced and whether its evidence is current. I made routing reasons and weak or stale evidence visible alongside the candidate, rather than burying them behind a score.
My contribution
I translated the buyer’s acquisition criteria into an explicit decision workflow. When source records exposed a routing mismatch, I corrected the underlying rule so future records could be handled consistently. More than 1,200 filings have been processed; that count is throughput, not an accuracy score.

How the system works

Step 1

Turn the filing stream into consistent inputs.

Qualification rules encode the operator’s criteria across Orange and Riverside counties. Source records remain available behind the candidate.

01 / INTAKE

Sources
Public foreclosure filings
Coverage
Orange + Riverside counties
Recorded throughput
1,200+ filings processed

Throughput is a processing count, not a measured accuracy rate.

Step 2

Expose the reason behind the score.

A candidate’s score travels with reason codes, source evidence, and freshness and confidence controls. Thin or stale evidence must remain visible.

02 / QUALIFICATION

Rules
Apply the buyer’s explicit criteria
Evidence
Supporting records + reason codes
Weak or stale data
Visible in review

The operator can inspect why a record advanced instead of relying on a score alone.

Step 3

Route the work to the right review state.

The pipeline organizes candidates into a CRM review queue. It supports the operator’s attention and preserves their authority over valuation and offers.

03 / ROUTING

PASS
Meets configured qualification rules
FAIL
Does not meet configured rules
REVIEW
Needs operator investigation

Qualification does not constitute a recommendation to purchase.

SecondLook + Case Clarity

Case reconstruction with page-level provenance, separate rule and reasoning layers, versioned analysis, and four-state review routing.

Working prototype; attorney pilot pending.

View engineering flow ↗

View full project

Inside the system · traced from implementation

Documents become evidence. Code makes the routing decision.

Google Apps Script coordinates intake, document processing and case reconstruction in Drive and Airtable. The analysis API extracts evidence, computes scores and applies its rubric before requesting an optional AI explanation. Separate projections serve the attorney interface, a facts-only packet and the partially built Case Clarity view.

SecondLook intake: labeled email attachments become linked Drive and Airtable records, OCR text, classified documents, repair history and identity fields, followed by completeness checks and analysis input.
01 · Intake and case reconstruction. Click to open at full size.
SecondLook analysis: evidence receipts feed deterministic scores and a decision rubric; optional AI interpretation has a deterministic fallback. Separate civil, shadow-routing and provenance layers support review. Outputs include consistent review status, a facts-only attorney packet and a partial Case Clarity client view.
02 · Decision authority, fallback paths and separate review outputs. Dashed boxes identify shadow mode or partial implementation.

Source review: September 9, 2026. Diagrams describe inspected repository code; they do not certify live deployment or end-to-end operation. Case Clarity is partially built.

Problem
A consumer case arrives as a pile of documents. Much of the intake burden comes from reconstructing what happened from incomplete or conflicting records.
Stayed human
The final legal judgment, always. SecondLook does not invent missing facts, hide contradictions, treat contextual inference as evidence, or silently override deterministic rules.
What I built
A system that reasons over the reconstructed case rather than over isolated documents. Every fact carries an evidence receipt — fact → source → page → observed value → confidence → verification state. Deterministic rule families stay separate from contextual reasoning. Unknown or incomplete inputs stay unknown and route to Discovery or Review instead of being guessed. Cases route to one of four states: Attorney Ready, Discovery, Review, or Hold / Alt Route.
How I tested
Analysis runs are auditable by design — trigger, engine version, dates, input-document count, output state, prior-run comparison, errors, review status. New evidence never overwrites history; it produces an auditable state change. The demo backend holds 15 sanitized tables. Run on one real case; no attorney customer yet.
Case Clarity
Case Clarity (designed, partially built) keeps declined matters in guided discovery, enriches missing facts and evidence, returns strengthened cases for attorney reconsideration, and flags civil signals for alternate legal routing.
System architecture
Documents become a reconstructed case record with fact-level evidence receipts. Deterministic rule families and contextual reasoning remain separate. The result routes to Attorney Ready, Discovery, Review, or Hold / Alt Route, with the analysis version and review state retained.
Hard problem
A document summary does not establish a reliable case history. Facts may be missing, contradictory, or changed by later evidence. The system keeps the observed value, source page, confidence, and verification state together so a reviewer can inspect the basis for a finding.
My contribution
I designed the evidence model and review workflow, including how new evidence changes the case without overwriting its history. I also identified the Case Clarity extension: guide declined matters toward missing evidence and reconsideration. That extension remains partially built; recovered revenue has not been established.
Evidence — case study pages
SecondLook case study page: evidence reconstruction
01 · Evidence reconstructionSanitized demo environment; synthetic data.
SecondLook case study page: reasoning engine
02 · Reasoning engineSanitized demo environment; synthetic data.
SecondLook case study page: decision, discovery and living intelligence
03 · Decision & discoverySanitized demo environment; synthetic data.
SecondLook case study page: product implementation evidence
04 · Implementation evidenceSanitized demo environment; synthetic data.
SecondLook case study page: source-aware backend evidence
05 · Backend evidenceSanitized demo environment; synthetic data.
Evidence — product UI and the record behind it
SecondLook product UI showing defect patterns with a cited repair order
Defect patterns, with the cited recordEvery pattern points back at the repair order it came from. Sanitized demo environment; synthetic data.
SecondLook product UI showing a repair history timeline
Repair history timelineReconstructed from the documents on the case file. Sanitized demo environment; synthetic data.
Airtable table of evidence receipts with verification status and confidence values
Evidence ReceiptsFact → source → verification state. Sanitized demo base; synthetic rows. Confidence values are illustrative, not measured accuracy.
Airtable table of decision routing showing attorney ready, discovery, review and hold routes
Decision RoutingAttorney Ready · Discovery · Review · Hold. Sanitized demo base; synthetic rows.

Scroll sideways for more. Click any image to enlarge.

How the system works

Step 1

Reconstruct the case with evidence attached.

The system builds a case record from documents rather than reasoning over disconnected summaries. Each important fact retains its provenance.

01 / EVIDENCE RECEIPT

Observation
Fact + observed value
Provenance
Source document + page
Review metadata
Confidence + verification state

Confidence is metadata for review; it is not measured accuracy.

Step 2

Separate rules from contextual interpretation.

Deterministic rule families stay separate from contextual reasoning. Missing or conflicting inputs return to discovery or review instead of being filled in.

02 / DECISION ROUTING

Ready for attorney review
Attorney Ready
Missing or uncertain facts
Discovery / Review
Other route needed
Hold / Alt Route

These are workflow states. Legal judgment remains with an attorney.

Step 3

Preserve changes and support reconsideration.

New evidence produces an auditable state change. Case Clarity extends the concept toward guided evidence collection for declined matters.

03 / HISTORY + FOLLOW-UP

Analysis record
Engine version, inputs, errors, review status
New evidence
State change with prior-run comparison
Case Clarity
Guided discovery · partially built

SecondLook has been run on one real case; attorney pilot remains pending.

RackCheck

Multimodal estimating: reconcile drawings and email requirements, validate dimensions, and gate catalog-matched bills of materials.

Working synthetic demo; real-drawing pilot pending.

Explore the interactive demo ↗

View full project
Problem
Estimators for pallet-rack dealers quote from an email plus a layout drawing, and the two disagree — the drawing says 42 bays, the email says 40, and whichever one the estimator read last becomes the quote.
Stayed human
Structural approval, and every quote. The system reconciles and flags; a qualified human signs.
What I built
A reconciliation pass over the email and the drawing that traces each extracted requirement back to its evidence, flags conflicts and missing inputs, and blocks BOM generation until a reviewer resolves the critical ones. Output is a bill of materials matched to catalog components. Pipedrive and QuickBooks adapters exist but run dry-run only.
How I tested
The current local demo passed behavior and responsive browser checks covering held outputs, recorded reviewer resolutions, and dimension failures. The underlying engine passed 18 unit tests. The earlier recorded evaluation used a blind run on 20 synthetic layouts scored against a held-back answer key. Adding two independent dimension checks took silent misses — a wrong number that would have reached a quote — to zero, at the cost of one false alarm. Validation on real drawings has not been done yet.
System architecture
Drawing and email inputs feed requirement extraction with source references. Reconciliation exposes conflicting counts and missing specifications; validation determines whether the request can advance. Resolved requirements feed catalog matching and bill-of-materials generation. Pipedrive and QuickBooks adapters remain in dry-run mode.
Hard problem
A plausible extraction can still produce the wrong quote. I treated extraction quality, agreement between sources, and permission to generate a bill of materials as separate checks. A drawing count and an email count can disagree without either being silently selected as the truth.
Design decision
Critical unresolved requirements block BOM generation. The reviewer resolves the conflict before catalog output can proceed. Independent dimension checks challenge the extracted numbers instead of trusting the model’s confidence alone.
Evaluation tradeoff
The recorded blind evaluation used 20 synthetic layouts and a held-back answer key. Adding two independent dimension checks produced zero silent misses within that evaluation, with one false alarm. That is a bounded test result, not a guarantee on unseen or real-world drawings.
My contribution
I designed the reconciliation workflow, evidence requirements, approval boundary, and evaluation approach, then used the observed failure modes to improve the validation rules. Structural approval and quote sign-off remain with a qualified person.

How the system works

Step 1

Two sources. One unresolved requirement.

The estimator needs a consistent specification before choosing catalog components. Each extracted value stays connected to the document it came from.

01 / INPUT RECONCILIATION

Layout drawing
42 bays
Request email
40 bays
Reconciled bay count
Unresolved conflict

Illustrative values, not a live quote or saved evaluation result.

Step 2

A confident extraction still needs a check.

Independent dimension checks challenge the extracted numbers. Agreement between sources and dimensional consistency are different conditions; both matter before the request advances.

02 / VALIDATION

Source check
Drawing count vs. email count
Dimension check
Extracted dimensions vs. bay × beam calculation
Critical disagreement
Flag for reviewer resolution

The system checks the proposed interpretation; it does not treat model confidence as verification.

Step 3

Missing evidence stops the output.

Critical gaps block bill-of-materials generation. The reviewer resolves the requirement before the system can proceed to catalog matching.

03 / APPROVAL BOUNDARY

Critical requirement
Unresolved
Bill of materials
Blocked pending resolution
Next action
Reviewer confirms the requirement

A reviewer’s resolution allows the workflow to advance; structural approval and quote sign-off remain human.

Step 4

Resolved requirements become catalog output.

The resolved specification feeds a catalog-matched bill of materials. The integration adapters remain in dry-run mode.

04 / OUTPUT + EVIDENCE

Output
Catalog-matched bill of materials
External adapters
Pipedrive + QuickBooks / dry run
Recorded evaluation
20 synthetic layouts · 0 silent misses · 1 false alarm

Evaluation result is limited to the recorded synthetic test set. Real-drawing validation remains pending.

RulePath

A deterministic quoting engine that validates inputs, executes business rules, and traces each result to the rule that produced it.

Working proof; 24 recorded passing tests.

Explore architecture & evidence
Problem
Landed-cost and quoting rules living in a spreadsheet, where the logic is real but invisible — no validation, no trace from an output back to the rule that produced it.
Stayed human
The quoting rules themselves — the engine runs them and shows its work; it does not change them.
What I built
A runnable decision engine with input validation and traceable outputs, delivered with packaged source, an architecture proof and demo videos.
How I tested
24 recorded tests passing. Not verified beyond the contained proof: production Excel I/O and Windows packaging were out of scope.
System architecture
Validated inputs feed the decision engine; its outputs preserve the connection to the quoting rule that produced them. The contained proof includes runnable source, an architecture proof, and recorded walkthroughs.
My contribution
I separated the business rules from the spreadsheet interface and made the calculation path inspectable. The engine executes the owner’s rules without changing them. The recorded proof has 24 passing tests; production Excel input/output and Windows packaging remain outside that proof.

Custom Payroll

A payroll reconciliation workflow translating timesheets, commissions, and pay exceptions into explicit rules and owner review.

In use by one owner for roughly 28 people.

View full project
Problem
A salon owner running a ~28-person payroll by hand across timesheets, commission structures and pay rules that lived mostly in her head.
Stayed human
Every pay decision. Exceptions, disputes, anything unusual — the system surfaces it, the owner rules on it.
What I built
A structured payroll pipeline: the rules written down as deterministic rules, the ambiguous cases routed to the owner instead of guessed.
How I tested
Reconciled against her own prior manual runs before she relied on it, then watched where it disagreed with her and fixed the rule, not the output.
System architecture
Timesheets, commission structures, and pay rules feed a structured calculation and reconciliation workflow for an approximately 28-person salon. Defined rules handle known cases; ambiguous cases return to the owner for a decision.
My contribution
I extracted the owner’s implicit pay rules, made them deterministic, and reconciled outputs against prior manual runs. Disagreements became rule corrections rather than one-off edits to totals. The owner retains responsibility for exceptions, disputes, and pay decisions.

How the system works

Step 1

Make the owner’s pay rules explicit.

The workflow connects timesheet inputs, commission structures, and exceptions for an approximately 28-person salon.

01 / INPUTS

Time
Timesheet records
Compensation
Commission structures + pay rules
Exceptions
Cases requiring owner judgment

No employee names or pay amounts are displayed.

Step 2

Calculate known cases. Escalate ambiguity.

Deterministic rules handle defined cases. Ambiguous inputs and disputes return to the owner instead of being guessed.

02 / RECONCILIATION

Known rules
Structured calculation
Mismatch
Compare with prior manual runs
Correction
Fix the rule behind the discrepancy

Reconciliation supports review; it does not authorize a payment.

Step 3

The owner remains the decision maker.

The system organizes the review while the owner decides unusual cases and pay outcomes.

03 / APPROVAL

Review package
Calculated results + exceptions
Human decision
Owner resolves disputes and unusual cases
Scope
In use by one owner

Every pay decision remains with the owner.

HVAC Revenue Recovery

Retell + GoHighLevel integration with dispatch scoring across urgency, technician qualifications, availability, and route proximity.

Test-mode prototype; no live operational deployment.

Explore architecture & evidence
Problem
A home-services contractor (plumbing/HVAC) losing jobs to unanswered calls — the owner is under a sink, the phone rings, the caller phones the next listing.
Stayed human
Quoting, scheduling commitments, and any call that reads as an emergency. The agent is designed to capture and confirm; it does not promise.
What I built
A callback agent on Retell AI wired into GoHighLevel for contact, pipeline and follow-up, plus a dispatch-routing layer scoring urgency, technician qualification, availability and route proximity.
How I tested
Scripted call scenarios in test mode — no live callers. 10 of 10 integration tests passing in test mode, with no live writes and no outbound actions. It has not been promoted to live routing and is not in use by anyone.
System architecture
A Retell callback agent connects to GoHighLevel contact, pipeline, and follow-up workflows. A separate dispatch layer scores urgency, technician qualification, availability, and route proximity to support review of the next action.
Opportunity I noticed
Capturing a missed call addresses only the first step. The next operational constraint is whether the right technician can serve that request within the surrounding schedule. I extended the concept to connect lead recovery with dispatch priorities.
My contribution
I designed the call-to-CRM workflow and the dispatch scoring layer, with explicit boundaries around emergencies, quotes, and scheduling commitments. Ten integration tests passed in test mode; live calling, routing, and operational impact remain unvalidated.

Real Estate Deal & Investor Workspace

A connected deal workflow linking shortlists, editable assumptions, investor document generation, and review-gated follow-up.

Interactive prototype with fictional data; no live research, AI, CRM, or email connections.

Explore interactive prototype ↗
View full project
Problem
Property research, investor materials, and follow-up often live in separate tools, making it difficult to keep deal assumptions consistent.
What I built
A connected interactive concept: shortlist opportunities, adjust a deal sheet, generate a template-based investor one-pager and draft deck, and prepare an editable follow-up for review.
Stayed human
Property verification, investment decisions, and approval of materials and messages. Sample permission records demonstrate a review gate; the prototype has no send function.
Verified behavior
Selected a sample deal, opened its investor workspace, generated draft materials, and prepared an editable follow-up. This is a self-directed concept, not a client implementation or a production deployment.
Production scope
Live property sources, scheduled research, AI-provider connections, CRM integration, and email delivery remain future integration work. Properties, contacts, and figures in this demo are fictional.
System architecture
The interactive concept connects a shortlisted property to its deal workspace, editable assumptions, template-generated investor materials, and an editable follow-up. Fictional data makes the full review sequence explorable without accessing real contacts or deals.
My contribution
I brought research, investor communication, and follow-up into one coherent review flow. I made the boundary explicit: the prototype generates drafts and has no send function. Live sources, AI providers, CRM connections, and delivery are future integration work.

How the system works

Step 1

Keep the selected deal and its assumptions together.

The interactive concept connects fictional opportunities to an editable deal workspace so the reviewer can explore a consistent scenario.

01 / DEAL REVIEW

Opportunity list
Fictional sample properties
Criteria
Editable acquisition assumptions
Deal workspace
Selected opportunity + scenario

Interactive concept with fictional data; no live property research.

Step 2

Generate materials from the deal sheet.

Shared deal assumptions feed template-generated investor documents for owner review.

02 / MATERIALS

Input
Editable deal sheet
Outputs
Investor one-pager + draft deck
Review
Owner checks figures and assumptions

Template generation, not a live AI-provider integration.

Step 3

Prepare the follow-up without sending it.

An editable draft stays connected to the selected deal. Sample permission records illustrate a review boundary.

03 / FOLLOW-UP

Draft
Editable investor update
Permission
Sample review records
Delivery
No send function in the prototype

CRM and email delivery remain future integration work.

More builds and experiments

Built to hand over

Scout dashboard

A dashboard you can run without me.

A replayable walkthrough of a wellness referral workflow, plus a preview of Ask Scout for questions about the setup.

Illustrative demo · sample data · scripted responses

Open the Scout demo ↗

Selected prototypes

  • Personal knowledge OS — organizes source material into a searchable base of principles and actions; in daily use (Think Simpul)
  • Correction-learning
  • Creator-opportunity scouting (Scout Simpul)
  • AI vision (Nest)
  • Consumer decision support (Pickwise)
  • Lead qualification (Sixgate)
  • HubSpot referral-revenue attribution demo

Briana Halim

From understanding the work to building something useful.

A decade in design and production taught me to connect intent with execution. Through Build Simpul, I apply that practice to business operations and AI.

Résumé Cover letter briana@buildsimpul.comLinkedIn