Why I Built 5C, and How

A plain explanation of the software, the AI tools I used to build it, and the small local AI it may one day run, written for Texas SSCCs, DFPS, child-placing agencies (CPAs), general residential operations (GROs), and any other organization that may encounter 5C in foster care and adoption case management.

Gerald (Jerry) Caldwell · 5C Systems · October 2026

Every screen and record shown on this page is synthetic demo data. No real child, family, foster home, or agency appears here, and no real case record has ever been entered into 5C.

1. Why I built 5C

A child-placing agency recruits, trains, and supervises foster homes, and it places children in them. Every visit, service plan, placement, and authorization becomes a record, and those records follow a child for years. A missing or wrong record can affect where a child lives.

5C started because a Texas child-placing agency director, my wife, a Texas-licensed psychologist, asked for a record system that fit the actual work. Several other Texas agencies have since shown interest. The bar I hold it to is one line from the 5C site: "If the visit is done and the note still isn't, the software failed."

The hard part is that the rules don't come from one place, and they move. A Texas agency answers to state statute, to HHSC minimum standards in 26 TAC Chapter 749, to DFPS rules and contracts, to its SSCC, and to federal law. HHSC adopted a revised Chapter 749 effective August 10, 2026 (Texas Register, Aug. 7, 2026), and DFPS updates the T3C System Blueprint quarterly. Software that hard-codes "today's rule" goes stale the next time the state publishes.

The basic 5C system is free to run, with no per-seat license, and it is designed to run on the agency's own machines rather than in the cloud. Most of this page explains why that second choice matters so much once AI enters the picture.

2. I design it; AI writes the code

I spent my career managing field operations and service technicians, and I've lived alongside child-placing work for years. I am not a traditional programmer who types code line by line. I am a developer in the modern sense: I design the system and direct AI tools to build it, the way a general contractor designs and directs a build without laying every brick.

Here is how the work divides:

Some of the design calls that came from reading the rules, not from the AI:

• Chapter 749 is the core; T3C is an overlay. The minimum standards will exist in some form no matter what happens to T3C, so 5C is built on them. An agency can run legacy Service Levels only, T3C only, or both during transition. That setting decides what can be recorded next; it never changes or hides past records.
• Rules are stored as dated data, not hard-coded. The initial service plan used to be due within 45 days under the old §749.1307, which was repealed when the revised Chapter 749 took effect on August 10, 2026 (Texas Register, Aug. 7, 2026). It is now due within 60 days under §749.1233(e), adopted without changes from the February 2026 proposal. 5C stores both, with dates, and uses whichever was in force on the date of the event. A home-visit note from August 9, 2026 is checked against the old elements; one from August 10 is checked against the new §749.1213, "Post-Placement Visits."
• Some rules are enforced by the database itself. A child can be authorized under a legacy Service Level or a T3C Service Package on a given day, never both.
• Less software where less is right. At the director's request, medication logs stay on the agency's paper form, DFPS case forms are uploaded rather than re-authored, and there is nowhere to type a background-check result.

3. Two kinds of AI that never meet

This is the most important idea on the page. When people hear "AI," they often picture one big system that sees everything. In 5C there are two completely separate kinds of AI, used at different times, in different places, for different jobs.

A simple way to hold it: the building tools are like the construction crew that built an office. The crew never reads the files that later go into the cabinets. The local AI worker is more like a records clerk who works only inside that office, reads a file when asked, points to the page, and goes home with nothing in their pockets.

4. The building tools, and why they never see real data

How a piece of 5C gets built

1. I read the rule and decide what 5C should do.
2. I work the decision out with Grok Bot into a numbered work order: exact written instructions for the coding tool, called a prompt, naming the rule sections, the behavior I want, and what must not change.
3. Claude Code follows that prompt to write the code and the tests.
4. The full automated test suite runs. The most recent full run, on October 7, 2026, ran 2,777 tests.
5. I review the result and click through it on demo data. If it doesn't match the rule or the practice, it goes back.

The tools I use, and only these

• Claude and Claude Code (Anthropic, a US company). I stood up the original version of 5C with them. Today Claude Code writes the code, but it writes exactly what I direct. Each change starts as my decisions, which I work out with Grok Bot into exact written instructions called a prompt (a prompt is simply the written instructions an AI tool is given). Claude Code follows that prompt to write the code, and I review the result.
• Grok Bot. Grok Bot deserves particular credit. It works with me as a project partner: it helps turn my decisions into detailed, numbered work orders (the prompts Claude Code follows), checks the results against the rules, researches rule changes, keeps the 5C user manual in step with every change to the software, and handles the careful, repetitive checking that keeps the documentation and data consistent. This page itself was drafted with Grok Bot from my notes and the project records, and I reviewed it.
• Small local models made in the US by non-PRC companies, run on my own hardware for testing. I choose not to use models built by, or built from, PRC-origin models, even when other developers point me toward them. That keeps my work inside Texas's guidelines (see section 8).

Where the demo data comes from

All development, test, and demo data in 5C is synthetic. I don't need a real child's record to build a correct form, because the form's requirements come from the law and the rules, not from any one case. The synthetic records are designed from what Chapter 749, T3C, and DFPS require a record to contain, and the narrative text is generated from the general knowledge that AI models already have about foster care. Every name is invented. Demo children use a reserved block of made-up ID numbers so they can never be mistaken for real ones.

The private copy prepared for my wife's agency has not been put into live use, and no live agency data has been entered anywhere in 5C. Real records will only ever live in an agency's own running database, never in the source code the building tools work on.

5. What this way of building makes possible

A fair question from anyone evaluating 5C is how one person could build a system this size. Here are the numbers, with the assumptions left showing so you can judge them yourself.

How big 5C is

What standard estimates predict for a traditional team

I didn't estimate my own project. Instead, I ran 5C's measured size through published software-estimation models, the way a software firm would bid it: Basic COCOMO and COCOMO II (Boehm, 1981; Boehm et al., 2000) and McConnell's (2006) productivity figures for business systems. Line-count models are rough, so I show a range: the code without its tests, and all Python lines.

Assumptions, stated plainly. KLOC means thousands of lines of code. "One developer" is effort divided by 12 months. COCOMO II counts a person-month as 152 working hours. McConnell's published range for this size, 200 to 7,000 lines per staff-month, spans roughly 9 to 550 person-months. AI-written code can be wordier than hand-written code, and these line counts include comments and blank lines, so the true "traditional" figure could be lower. On the other side, COCOMO II's effort starts once requirements are set: a traditional team would first have to study the rule corpus itself (the statute, Chapter 749, the DFPS rules, and the T3C documents), and I found no published figure for that domain work, so none is added. These figures are for 5C's full size today, not its first version.

What it actually took

The difference between those two tables is the point of this section. My hours went into the parts a person must own: reading the rules, deciding what the record should do, writing numbered work orders, and checking every result against the rules and the practice. Claude, Claude Code, and Grok Bot did the typing, the testing, and the record-keeping, far faster than any of it could be done by hand. That is what AI-assisted building under a human architect makes possible.

It is not a claim that 5C is finished, or that one person replaces a team in every case. One builder carries real load and real risk, which is why every change runs the full test suite and why the limits are listed openly in Where 5C stands today. It does mean an agency-grade system built from Texas rules no longer requires a large software budget, and that the savings can be passed on: the basic 5C system is free to run.

6. The local AI worker: a clerk, not a decision-maker

5C works fully without any AI, and the basic 5C system is free. The AI worker is not free: it is a separate, paid add-on. Everything on this page about the local worker describes that optional add-on, which is switched off by default and is off in the current test copy. It stays off at an agency until DFPS has given written approval for its use (see DFPS's contractor security terms).

What it is

The planned worker is a small language model, fine-tuned for one kind of job: reading agency records and pointing to what is there. Its base will be a small, US-made, non-PRC model. The fine-tuning hasn't been run yet; I paused it on purpose until the rest of the system is settled.

The posture I designed for it is a records clerk: find, extract, organize, and cite. It does not practice casework and does not give legal advice.

What it does (for a person to review)

• Point to where a note covers each required element. The one AI feature already in the code reads a monthly home-visit note and, for each element the rule required on the visit date, quotes the words in the note that cover it. 5C then checks that each quote really appears in the note, and flags any quote it can't find so a person looks closer. The caseworker and supervisor decide whether the note is complete.
• Find, extract, and organize. Pull facts out of records and documents and lay them out so staff don't have to retype them. A person reviews every item and decides whether anything is saved.
• Look up the rules. Show what a rule says and cite where it says it, without offering an opinion.

What it does not do

• It can't change the record. In the code's own words, its findings "change nothing, block nothing, and have no approve button." Anything the AI extracts waits in a review queue, and a person decides whether it goes into the legal record. Nothing is saved automatically.
• It plays no part in placement decisions. 5C's "Possible homes" list shows credentialed homes and how many children each has. It does not rank them, and it "decides nothing and writes nothing." That list is plain database logic, not AI.
• It isn't asked what a database can answer. Dates, counts, and credentials come straight from the database. The AI only reads narrative text.
• It is always labeled. Every AI finding is marked as AI-generated, with the model and the time.

Where it runs

The worker is designed to run on a computer the agency owns, in its own office, alongside 5C. 5C reaches it at an address the agency sets on its own machine or local network. 5C has no built-in account with any AI company and no cloud AI address. The worker is built to run with no internet connection, and it makes no outside calls.

When AI is off, which is the default, 5C uses a placeholder that, in the code's words, "runs no model and opens no socket." The code was written that way on purpose, so that a misconfigured install can't quietly send a child's information anywhere.

For IT reviewers: this is easy to confirm rather than take on trust. The AI address is a single setting you control. You can point it at a local machine and block outbound internet traffic from that machine at your firewall. The worker will run the same way.

The model is small enough that an affordable computer or GPU system is all an agency would need to run it. I can help an agency with choosing and setting up that hardware.

7. "Can the AI remember a child?"

This is the fear I hear most often, and it deserves a clear answer.

The model itself does not remember. A language model's knowledge is fixed when it is trained. When it reads a record to answer a question, it uses that text for that one task, and when the task ends, the model is unchanged. It does not learn from what it reads while it is running, and it doesn't carry one child's information into the next request. The planned 5C worker is trained only on synthetic examples, never on agency records.

5C's database does keep the records, and that is its job. It's worth saying plainly so no one feels misled later. The child's record lives in the agency's own database, on the agency's own computer, under the agency's control, the same as it would in any record system. When staff ask the AI to check or find something, it reads that record, gives its answer with a quote, and keeps nothing. The answer it gives is saved in 5C, labeled as AI-generated, so staff can see what was said and when.

So the honest summary is: the records stay in the agency's database; the AI reads them only when asked, keeps nothing, and isn't trained on them.

8. Texas rules: non-PRC technology and DFPS's contract terms

The state's prohibited-technology rules

Texas has restricted technology tied to the People's Republic of China (PRC) in steps:

• 2023, statute. SB 1893 added Chapter 620 to the Government Code. It requires each governmental entity to "adopt a policy prohibiting the installation or use of a covered application on any device owned or leased by the governmental entity," and lets the Governor name more covered applications by proclamation (SB 1893, 88th Leg.).
• 2023, statewide model security plan. Its objectives include: "Prohibit employees or contractors from conducting state business on prohibited technology-enabled personal devices" (Office of the Texas Governor, 2023).
• January 2025. PRC-linked AI and social media apps were added to the prohibited list. DIR describes them as "banned from all state-owned devices and networks, and from personal devices that are used to conduct state business, effective January 31, 2025" (DIR, 2025; Office of the Texas Governor, 2025).
• January 2026. The list grew to include PRC AI developers such as Alibaba, Baidu, Zhipu, Moonshot AI, and MiniMax (Office of the Texas Governor, 2026).

Those measures apply directly to state agencies, their devices and networks, and to devices used for state business.

DFPS's contractor security terms

For SSCCs and child-placing agencies, the binding instrument is contractual: DFPS's Data and System Security Requirements (Ver 3.4, June 29, 2026). Vendors with access to DFPS information "agree to be bound by these Requirements" and to impose them on their subcontractors. The parts that matter most here, in DFPS's words:

• Art. 5.C, US only. Storing or transmitting Sensitive Information "outside of the United States, or access of Sensitive Information from outside the United States, is prohibited unless the Vendor obtains prior written authorization from DFPS."
• Art. 5.D.2, prohibited countries. "The Vendor is prohibited from entering into any agreements, contracts, or purchases of hardware or software from companies that are owned or primarily controlled by citizens from China, Iran, North Korea, Russia, or any other country designated by the Governor under Government Code Section 2274.0103, or if these countries' governments control any companies themselves."
• Art. 5.F, data ownership. "DFPS owns all rights, titles, and interests in any data or Sensitive Information provided to the Vendor that is related to any services the Vendor may provide under this Contract."
• Art. 13.A, notification. "Prior to procuring any system or technology solution that will process information provided by DFPS, the Vendor must notify DFPS in writing to their Contract Manager and the DFPS CISO of their intent to do so."
• Art. 13.C, written approval. "Upon DFPS's satisfactory review of the proposed system procurement, the Vendor will receive written approval to proceed with the procurement. This written approval must be obtained before any financial commitments are made, contracts are signed, or systems are acquired."
• Art. 13.D, AI needs written approval first. "If the vendor plans to utilize any new or emerging technologies, such as Artificial Intelligence (AI), Machine Learning (ML), Application Programming Interfaces (APIs), cloud computing, or any other technology that may process, store, or share DFPS data, it is mandatory first to request written approval from DFPS."
• Art. 14, flow-down. The vendor must ensure its subcontractors do not buy hardware or software from companies "headquartered, owned, or primarily controlled by citizens from China, Iran, North Korea, Russia."

Keeping the records and the AI on site is meant to make DFPS's review questions easier to answer clearly, not to skip the review.

Articles 13.A and 13.C set out the steps for procuring a system that will process DFPS information: written notice to DFPS first, then DFPS's written approval before any commitment is made. I'm aware of these steps and am working toward them on my side, so that an agency's notification and approval request can be straightforward.

How 5C is built to fit

• The software an agency runs, and every component it depends on, is of non-PRC origin. That includes the web framework, the database, the screen components (stored with the software rather than loaded from outside servers), and the server images.
• The planned AI worker's base model is a small, US-made, non-PRC model.
• The building tools I use are Claude, Claude Code, and Grok Bot, plus small US-made, non-PRC local models.
• Installed on the agency's own machines, the records stay in the agency's building in Texas.

The public site says it in one line: "Made in Texas. Built with U.S. tools only."

9. Where the internet does and doesn't come in

5C is installed on the agency's own machines. It is not a website hosted somewhere else that staff log into. The places it touches the internet are few, and each is something the agency controls.

What doesn't go online: the AI worker's processing, the agency's database, and its stored documents. They stay on the agency's machines. The building tools are not part of the installed software at all.

MFA is built into 5C. Every real install asks for a password and then a passkey, for staff and administrators alike, with no email, text-message, or app codes. Administrators use a separate login from their everyday staff login, and every sign-in, refused attempt, passkey change, and reset is written to a security log. DFPS's contractor terms set the bar: Art. 9.C says "the Vendor must implement MFA for both local and remote access to all systems, including administrative accounts," and Art. 9.A.1 calls for phishing-resistant methods such as "FIDO/WebAuthn Authentication, PKI-based MFA, or Number Matching MFA," adding that "Email, SMS (or text-based) MFA, or Voice MFA are not approved and should only be used as a last resort" (DFPS, 2026, Art. 9). A passkey is FIDO/WebAuthn, so 5C is built to meet Art. 9.C's phishing-resistant MFA requirement for local and remote access. The current test copy, which holds only synthetic data, keeps MFA switched off so testers can reach the demo easily.

10. Safeguards that don't depend on AI at all

Much of what protects a child's record in 5C has nothing to do with AI. These are built into the software today:

• One role per login, deny by default. Each login is an Administrator, Agency Staff, or Foster Parent. A screen that doesn't name who may see it is refused. Foster parents see their own home's information and never see any child's record.
• Password plus passkey. Every real install asks for a password and then a passkey (Windows Hello, Touch ID, a phone, or a USB security key). An administrator's login is separate from their everyday staff login, and every sign-in, refused attempt, and passkey change goes into a security log.
• Automatic logout. Sessions end after 60 minutes idle and when the browser closes, because, as the settings file puts it, "the machine this runs against is a shared desk in an agency office and the record on screen is a child's."
• Nothing is silently overwritten. "Every correction is kept — the original value is never lost," with who made the change and when.
• Signatures that show tampering. A drawn signature is tied to a fingerprint of the signed fields. If the fields are edited afterward, the screen says the mark "no longer matches what was signed."
• Private document storage. Uploaded files are stored under random IDs with no names in the file paths, and there is no public web address that reaches a stored file. Every download goes through a login.
• Take your data with you. An administrator can start a full data export at any time: every table, including the change history, and every document at its original bytes, packaged with a manifest and a checksum for each file. It was built for an agency that decides to leave.

11. How this differs from other vendor systems

When an SSCC, DFPS, a CPA, a GRO, or any other foster care and adoption organization asks "where does our data live, and where does the AI run?", the answer depends on how a product is delivered. I looked at what the vendors whose systems Texas agencies use, or might consider, say about their own products. The table below quotes their public pages. These are the vendors' own statements, not my characterizations. Several of these products hold the state's TX-RAMP cloud certification.

Sources checked Oct 7, 2026. Vendor pages change; this table describes what each vendor said publicly on that date. Corrections from any vendor are welcome. TX-RAMP is the state's certification for cloud services; DFPS's terms note that Texas Government Code 2054.0593 requires state agencies to "only enter or renew contracts to receive cloud computing services that comply with TX-RAMP requirements" (DFPS, 2026, Art. 5.E; DIR TX-RAMP list).

A plain note on how cloud AI features work

When a cloud AI feature works on case content, for example summarizing notes, drafting documentation, or turning a recorded visit into a draft, the content it works on has to be sent to that cloud AI model to be processed. That content can include a child's information, unless the vendor removes identifying fields first. That is simply how such features work, for any cloud AI.

Vendors describe protections around that step. In their own words:

• Binti: our AI models never store or train from your data (vendor statement).
• Bonterra: Your data is never used to train LLMs. Data is used only in the moment a skill is activated and is not retained or reused. PII fields are removed before data moves through the model. (vendor statement)
• CaseWorthy, for its not-yet-released Cara: All Cara AI processing occurs within our secure, certified infrastructure and Customer data never leaves CaseWorthy infrastructure (vendor statement).

5C's design takes a different path to the same goal. Its optional worker processes that content on the agency's own computer, so the text being worked on is not sent to an outside AI service to be processed. Either way, DFPS's written approval under Art. 13.D comes first.

The broader tradeoff

Neither shape is automatically right for every agency, and on-site software does put more responsibility on the agency. I chose local installation because a child's record and any AI that reads it belong in the building, under the agency's control, subject to the same DFPS review as any other system.

12. Where 5C stands today

I'd rather you hear the limits from me:

• A test copy runs on synthetic data for a small group of testers. No agency is using 5C with real records yet.
• The public 5C user manual is live and explains every screen in plain terms.
• AI is off by default and off in the test copy. The completeness check's accuracy will be measured on the chosen non-PRC model, and the worker would be submitted to DFPS for written approval under Art. 13.D, before any agency turns it on. The fine-tuned worker has not been trained yet.
• An AI-assisted version is planned. Down the road, there will also be an optional AI-assisted version that runs on its own dedicated computer. That will be a paid add-on, and I’ll share details when it’s ready.
• MFA is built in. Every real install requires a password plus a passkey for local and remote access, with separate administrator logins and a security log, built to meet DFPS Art. 9.C's phishing-resistant MFA requirement. It is intentionally left off in the synthetic-data test copy.
• Some features aren't built yet, including automatic notifications, a records-retention job, and caseload-level access limits for staff.
• GRO support isn't built yet. The rules and data it needs are already gathered, and adding it is about a day or two of work.
• 5C is not legal advice. It cites rules; it doesn't interpret them for an agency.
• The rules will keep moving. 5C is built to absorb changes, but I can't promise the next edition is handled until it arrives.

The scale as of October 8, 2026: 19 application modules, about 75 kinds of records, 152 screens and routes, and over 2,700 automated tests, built from July 2026 forward.

13. Common questions

A closing word

The fear of AI in child welfare is reasonable. Children's records are among the most sensitive information any of us handle, and much of the AI in the news runs on someone else's servers. I built 5C on a different footing: the state's rules are the specification, a person designs the system, the AI tools that write the code never see a real record, and the only AI that might ever read a record stays on the agency's own computer, keeps nothing, decides nothing, and is used only after DFPS approves it in writing. People make every decision.

I'd welcome the chance to walk through it with you. A demo runs on synthetic data, and the user manual is open to anyone.

References