Existing consumer parental controls operate at the device or account layer (iOS Screen Time, Google Family Link, platform-specific safety settings, monitoring apps installed on a child's phone). All of these depend on the child's primary device being the observed device, and all are routinely circumvented through new accounts, secondary devices, app substitution, or simple settings changes.

C.A.P. operates one layer below — at the home network level — which provides parents with awareness of patterns visible across every device on the home network, regardless of what software is running on the device. To our knowledge, no current consumer hardware product addresses this layer with a focus on child-safety behavioral patterns. C.A.P. is positioned to fill that specific gap, not to replace any other tool.

It is a hybrid. The detection engine combines four parallel detectors:

• Signature matcher — high-throughput pattern matching using established multi-pattern algorithms (Aho-Corasick with SIMD acceleration) against curated indicator sets. Rule-based.
• Behavioral analyzer — gradient-boosted ensemble model trained on flow-metadata features documented in published online-grooming research. Machine-learned, with rule-based overlays.
• Flow correlator — heuristic cross-platform linking on metadata only. Rule-based.
• Content classifier — cryptographic hash matching against published NCMEC hash sets. Deterministic.

Outputs from all four detectors feed a weighted-fusion layer that produces a single 0–100 risk score with a confidence band. Detectors do not act independently; no single rule fires an alert without fusion. This architecture is the patent-pending core, filed under reference IBR-CAP.

The founder is a U.S. military veteran with 25+ years of professional experience as an IT engineer and architect, spanning enterprise infrastructure, network architecture, security engineering, and hardware-software integration. These are the precise disciplines required for a network-layer hardware appliance with cryptographic evidence-handling.

The founder is also being honest with reviewers about the disciplines that complement his core expertise — child-development research, forensic admissibility law, and IRB ethical review — and the company has budgeted for outside expertise in each. These are not areas where IBR-Tech is claiming expertise it does not have.

It could not, for two reasons. First, software running on a child's device can be disabled by the child — a router-on-the-network appliance cannot. Second, software cannot inspect traffic from devices it isn't installed on (game consoles, smart TVs, IoT devices, friends' devices brought into the home), while a network-layer appliance sees all of them.

Hardware also creates a sustainable business model that does not depend on app-store distribution, subscription churn, or platform-policy changes — all of which have crippled previous attempts to build consumer child-safety software.

Each captured-data package contains the relevant network capture, detector outputs, device attestation (TPM 2.0 quote of firmware state at the moment of capture), and a Merkle-tree root binding all artifacts. The Merkle root is signed by an Ed25519 key generated and held inside the device's TPM secure element. The signed root is then countersigned by an external RFC 3161 Trusted Timestamp Authority, providing independent time verification.

Local storage uses an encrypted write-once partition. Cloud replicas use object-lock immutable storage. Verification of any package is possible without contacting IBR-Tech, using only the published intermediate CA public key.

No, and we are explicit about this in the grant application. Admissibility under the Federal Rules of Evidence (901, 902) and applicable state rules is a determination made by courts on a case-by-case basis. IBR-Tech provides the technical substrate that admissibility arguments typically rely on — origin authentication, integrity binding, independent time verification, tamper evidence, and provenance attestation — but the legal outcome of any particular use of that data is not something a vendor can guarantee.

We describe captured data as "stored if requested for a legal proceeding," not as "suitable for legal proceedings," precisely because we are not the body that determines the latter.

This is in active progress. The current grant application reflects design decisions made on the basis of published literature, NCMEC public guidance, and the founder's professional network. As part of the project plan, IBR-Tech is initiating direct outreach to PA cyber-crimes practitioners (PA OAG ICAC Task Force, PA State Police Computer Crime Task Force, county-level cyber detectives) for practitioner guidance on evidence-handling design.

We are not claiming endorsements or partnerships we do not yet have. We are also not waiting for those conversations to happen before submitting grant applications — but we will incorporate practitioner feedback into the design before the product ships, and any architectural changes will be reflected in subsequent grant updates.

The NCMEC CyberTipline is the established public reporting channel for suspected online exploitation of minors — any member of the public, any electronic service provider, any organization can submit reports. C.A.P.'s architecture provides a parent-initiated reporting pathway that submits a properly formatted CyberTipline report on the parent's behalf when the parent chooses to do so.

This is correctly described in the grant application as "an architectural pathway for integration with the NCMEC CyberTipline reporting framework." It is not a special partnership or formal MOU with NCMEC. Any consumer product can architect to this pathway; what we are claiming is that we have done so deliberately, with appropriate metadata formatting and chain-of-custody preservation.

IBR-Tech does not currently hold and does not claim to hold any formal agreement, MOU, or technical integration with FBI, DHS, ICE, or other federal or state law enforcement databases. Any such integrations would require formal agency agreements and CJIS-compliance certifications that take significant time and agency-side sponsorship to establish.

If we pursue these in the future, we will disclose them clearly. They are not part of the V1 product claim.

This is the most important technical challenge for any network-layer child-safety product, and the honest answer requires care. C.A.P. does not perform TLS interception. It cannot read the content of encrypted messages. What it does see, even on encrypted traffic, is metadata: which platforms a device is communicating with (via SNI), DNS queries, flow timing, volume patterns, contact-frequency trends, and the timing relationships between flows on different platforms.

Published online-grooming research has documented substantial behavioral signal in this metadata layer — escalation of contact frequency from a new external party, off-hours session clustering, platform-hopping from public to private channels within short time windows. C.A.P.'s behavioral analyzer is built on these documented signals.

What this means in practice: C.A.P. is not a content-monitoring product. It is a behavioral-pattern product. We do not claim it would detect every predatory interaction — we claim it surfaces patterns parents would otherwise be unable to see at all.

Yes — and the grant application states this directly in Section 11. C.A.P. is bypass-resistant against device-level evasion (settings changes, account recreation, app substitution, browser incognito mode), but it is not bypass-proof. A child using cellular data exclusively, or operating exclusively on networks outside the home, is outside C.A.P.'s visibility.

C.A.P. addresses VPN usage by detecting it at the network level — a VPN appearing on a household device is itself a parent-notification event, on the reasoning that a child installing traffic-concealment tooling is information worth parental awareness regardless of the underlying use case. C.A.P. does not claim to defeat traffic tunneled through a trusted VPN.

A positive hash match against an NCMEC-published list immediately triggers maximum-severity evidence sealing and surfaces a high-priority alert to the parent with explicit guidance on the NCMEC CyberTipline reporting pathway. Reporting itself remains parent-initiated — IBR-Tech does not autonomously report on a family's behalf — but the system is designed to make that reporting straightforward when the parent chooses to act.

C.A.P. is at reference-design status. The architecture is documented (see IBR-CAP-ARCH), the patent application is filed, and the grant funding sought in this application is specifically scoped to the path from reference design through certification and initial production over a 24-month execution window. We are not asking grants to fund a finished product or to subsidize ongoing operations — we are asking for the bridge funding consumer hardware historically lacks.

The beta plan is documented separately (see the C.A.P. Pilot Deployment Plan). Key elements:

• Independent IRB or equivalent ethical-review approval before any household receives a device.
• Written informed parental consent and age-appropriate child assent.
• Categorical exclusion of households in active custody disputes or open child-welfare cases.
• An adverse-event protocol that does not place IBR-Tech in a mandatory-reporter role it is not legally positioned to fulfill.
• Right to withdraw at any time, with data destruction within 30 days.
• Parental-consent-based outcome data collection — no content data, only metadata and parent-rated alert utility.

Initial 500-unit production is planned with a U.S.-based contract manufacturer to align with Buy-American procurement preferences. Component selection emphasizes parts available from multiple distributors to reduce single-source supply risk. Production timeline targets months 15–19 of the 24-month grant execution window, after FCC Part 15 and UL 62368 certification milestones.

This is a serious question that grant reviewers correctly ask of any small-team venture. IBR-Tech maintains technical documentation, source code, and patent prosecution materials in formats that are independent of the founder. A succession plan establishes that, in the event the company cannot continue, the IP and pilot-collected data are transferred to a designated child-safety nonprofit partner under terms that protect pilot families' privacy. Specific arrangements are being finalized as part of partner conversations.

Pilot family data remains protected regardless of company continuity — the pilot-deployment plan requires destruction-on-withdrawal at any time, including an orderly destruction protocol if the program were discontinued.

Honestly. The primary success metric is parent-surfaced behavioral-awareness events — the number of moments where a parent, because of C.A.P., became aware of a pattern they would not otherwise have seen. We deliberately do not claim arrests, prosecutions, or rescues as success metrics, because those are law-enforcement outcomes attributable to many factors, and a vendor claiming credit for them tends to mislead reviewers.

Secondary metrics include: technical reliability (uptime, latency), parent utility (rating distributions on alerts), false-positive tolerance, household retention through the pilot, partner-engagement outcomes, and zero product-caused household harm events. These are captured in Section 7 of the pilot plan.

As an unavoidable cost of doing this work, and one we plan to measure honestly. The fusion-based detection architecture is designed to keep low-confidence single-detector signals from generating alerts on their own — a positive risk score requires corroboration across detectors. The household-tunable threshold tiers (digest, immediate, urgent) ensure that only the highest-confidence cases produce immediate notifications.

The pilot will report observed false-positive rates as part of standard reporting. We are not aiming for "zero false positives" — that would mean we had set the threshold so high that we missed real cases — but for a rate that pilot parents find acceptable in exchange for the awareness the system provides.

The most direct public benefit is household-level: each deployed C.A.P. device is a household with earlier visibility into at-risk online behavioral patterns. A secondary public benefit is structural — a credible, commercially available consumer-grade hardware option in the child-safety space changes the baseline of what American families can reasonably expect from this category of technology. A tertiary public benefit is veteran-economic: a successful veteran-owned hardware company in public-safety technology demonstrates a path other veteran entrepreneurs can follow.

Because more established organizations have largely not built this. The consumer-hardware child-safety space is structurally underserved by large vendors — the unit economics, regulatory complexity, and reputational risk discourage incumbents from entering. Grant funding for early-stage veteran-owned hardware in public-safety technology directly addresses this market gap. IBR-Tech is not the only organization that should be working in this space; we are simply the one currently doing it, with the technical depth and the founder credentials to do it credibly.

IBR-Tech is building hardware for American homes that addresses problems the consumer-software market has structurally failed to address. C.A.P. is the company's child-safety product — a hardware appliance that gives parents household-level awareness of online contact patterns affecting their children.

We are not a charity, and we are not pretending to be one. We are a for-profit veteran-owned small business that has chosen to focus on a problem space where the right product is mission-aligned by nature. We expect to build a sustainable company while doing this work.

Yes, on both counts. The founder is a U.S. military veteran with 25+ years of professional IT engineering and architecture experience. His military service is documented and verifiable through standard channels (DD-214, VA records).

It is relevant in two ways. First, veteran-owned status creates real federal procurement advantages that affect IBR-Tech's go-to-market — including child-safety procurement at the federal and state levels where partnerships with established nonprofits are often required. Second, the founder's perspective on this work — that protecting children online is "a second mission" — is genuine and shows up in how the company makes design decisions, including ones that prioritize safety over feature surface area.

C.A.P. is intentionally designed to complement existing tools, not to replace them. NCMEC remains the established federal channel for online-exploitation reporting; C.A.P.'s architecture supports parent-initiated reporting through that channel. Device-level parental controls remain valuable; C.A.P. operates one layer below them on a different signal entirely. Crisis hotlines, in-school counselors, and community-based child-protection organizations remain primary resources for any household navigating an actual situation; C.A.P. is a notification tool, not a response tool.

We see C.A.P. as one tool in a larger ecosystem, and our partnership posture reflects that.

Three categories, in rough order of formality:

• Advisory relationships — partner organizations that lend domain expertise to C.A.P.'s design, particularly on consent processes, age-appropriate communication with children, and adverse-event protocols. Time commitment is typically a few hours per quarter.
• Pilot recruitment partnerships — partner organizations that help IBR-Tech identify families willing to participate in the 50-household beta. The partner organization does not endorse the product unconditionally; it simply makes the opportunity known to families it serves who may be interested.
• Letters of support for grant applications — partner organizations whose mission alignment with C.A.P. is genuine and who are willing to put that on paper for grant reviewers.

We are not currently seeking endorsement-as-marketing relationships, paid sponsorship arrangements, or any partnership that puts the partner organization in a position to recommend C.A.P. to families they have not personally evaluated.

Honestly, less than larger vendors typically offer — and that is intentional. We are not in a position to offer significant cash compensation, and we are wary of compensation arrangements that could compromise a partner organization's independent judgment.

What we can offer:

• Direct input into product design from organizations with operational expertise we lack.
• Access to de-identified pilot outcome data for legitimate research or program-evaluation purposes (with appropriate data-use agreements).
• Honest credit for the partner organization's role in shaping the product — including in published materials, case studies, and grant reports.
• Joint application paths to funding programs that prefer or require nonprofit participation alongside small-business technology developers.

Not in its current form. C.A.P. as designed is a household tool — its detection logic, age-profile calibration, and consent model are built around the family unit. School-district deployment is a different product in important ways: it requires district-level consent frameworks, alignment with student-privacy laws (FERPA, COPPA, state-specific student-privacy statutes), and a fundamentally different approach to alert routing (school counselors, not parents, in many cases).

A school-district variant is something IBR-Tech is interested in pursuing as a future product line, with the right partners — but it is not what is being applied for in the current grant application, and we would not deploy the household version into a school environment.

The pilot deployment plan addresses this directly. If C.A.P. surfaces an alert indicating possible ongoing harm in a pilot household, the parent receives the notification through the C.A.P. mobile application as the product is designed to do. If the parent reaches out to IBR-Tech, IBR-Tech provides guidance on the NCMEC CyberTipline as a reporting pathway and, for PA households, contact information for the PA ICAC Task Force.

IBR-Tech does not initiate third-party contact (law enforcement, schools, child welfare) without explicit parental request. This is a deliberate boundary: vendors who initiate reporting on a family's behalf without context have caused real harm in cases where the situation was misread, and we do not believe a hardware company is the right entity to make that call.

Mandatory-reporter analysis is part of the pilot's pre-launch legal review. Individual IBR-Tech staff who hold mandatory-reporter credentials in another professional capacity continue to carry those obligations personally.

Pilot-collected data is described in detail in the pilot deployment plan (Section 5). The short version: device telemetry, detection-event metadata (no content), parent-rated alert utility, household feedback survey responses, and de-identified adverse-event records. Retention is 24 months plus a 12-month audit tail, then destruction. Households can request earlier destruction at any time.

Partner organizations are welcome to review the pilot's data-handling protocols as part of an advisory relationship — we expect this and welcome the scrutiny. Independent IRB or equivalent ethical review is contracted and provides an outside check on the protocol before any household receives a device.

By design, C.A.P. surfaces patterns to parents for review — it does not name accused third parties, does not initiate contact, and does not produce outputs intended for direct presentation to anyone outside the household without parental review. The fusion-based detection architecture is designed specifically to avoid single-signal false alarms.

We are aware that any technology that labels behavior as "concerning" carries risk of misinterpretation. The product's user-experience design includes explicit framing that alerts are signals warranting parental conversation, not conclusions about anyone's character or intent. The pilot's adverse-event protocol includes review of any case where C.A.P.'s output may have contributed to a harmful outcome.

We will not build content-monitoring features that intercept and read encrypted child communications. We will not build autonomous-response features that take action against accused third parties without parental and law-enforcement involvement. We will not build child-tracking features that extend C.A.P. beyond the home network. We will not build features that route family data through advertising or data-broker channels under any circumstance.

These are not aspirational limits — they are constraints on the company's product roadmap, and they will be reflected in the patent filings and in any grant-funded development.

A 30-minute video call. We will share what we are building, what we are asking, and what we can offer. We will listen to what your organization sees in the field that we should know about — particularly things that contradict assumptions we have made. We will not ask for a commitment in the first call, and we will follow up within 48 hours with a written summary of what we discussed and what next steps make sense.

If a partnership is the right fit, we will propose a specific structure. If it is not, we will say so.

By designing the product, the pilot, and the public messaging in ways that we would be comfortable being publicly associated with — and by giving partner organizations approval rights over how their name appears in any public-facing IBR-Tech material. Partner organizations are not used as marketing collateral without explicit written approval of the specific content in question.

If partner organizations identify product or messaging choices that create reputational risk, we expect to hear about it and to take it seriously. The partnership is not worth keeping if it requires a partner to defend something they would not have signed off on.

That is normal and welcome. Many child-safety organizations have policies that limit formal vendor partnerships. There are lighter-weight ways to engage — informal advisory conversations, introductions to other organizations or practitioners, public expressions of support for the broader category of veteran-built child-safety hardware, or simply ongoing dialogue as the product evolves.

We track these relationships honestly. An organization that has been generous with informal guidance will be acknowledged accordingly, even where a formal partnership is not possible.

Direct contact information is provided on request. The founder personally handles initial partnership conversations and will continue to do so until the company scale makes that impractical. Email is the most efficient first contact, with a brief description of the organization and the type of relationship under consideration.