Questions
Direct answers to the hard questions
These are the questions we expect from a Cyberport panel, a technical reviewer or an investor, answered as they stand today. Where evidence is pending, the answer says what the next test is.
- Is IRONWARD built?
- The engineering preparation is detailed; a qualified product is not yet built. We have component requirements, acceptance cases and staged work packets. The visual presentation on this site is a design preview until it is replaced by accepted runtime footage.
- Why would a customer pay for it?
- Our hypothesis is that a small technical team values clearer, faster completion of security work with inspectable evidence. We have to test that against its current workflow and willingness to pay. The initial pilot measures accepted outcomes, operator effort, regressions and direct cost. A beautiful interface alone is not commercial validation.
- Is this just Prime with security prompts?
- Prime is the reused agent harness. The proposed IRONWARD product adds durable task and action contracts, an isolated execution broker, qualified tool adapters, independent verification, recoverable workflows and operator evidence. Those layers still need implementation and testing. Reuse is part of the strategy; we do not claim to have invented the upstream harness or the scanners.
- Why not buy an existing security platform?
- That may be the right decision for some buyers. Our entry hypothesis is a specific follow-through workflow with deployment choice and explicit outcome verification. We will compare it with the customer’s actual alternatives. We do not yet have evidence to claim superior coverage or lower cost than a named incumbent.
- Why use several agents?
- Separate roles can investigate independent questions and challenge a repair. They also add coordination and cost. We will compare a deterministic baseline, one agent and a bounded swarm under matched budgets. Role separation does not automatically make judgments independent when models or evidence share the same blind spots.
- Can an agent break a customer’s environment?
- An incorrect action can cause harm. The design limits effects through external authorization, worker confinement, exact plans, durable intent and verification. Initial work emphasises read-only inspection and scratch repairs. We will not claim unrestricted autonomous production remediation or universal safety from finite tests.
- What does “locally controlled” or “uncensored” model mean here?
- The founder wants control over locally served models, including suitable variants for authorised defensive research. Model behaviour and system permissions are separate. A modified model is qualified separately and receives no additional credentials. Customer-facing language emphasises local processing and operator control; technical diligence names the actual weights and evaluations.
- Does four-Spark DeepSeek already deliver the quoted speed for IRONWARD?
- No. We have attributed external benchmark records with different dates and workloads. AIFLOWLABS has not reproduced them or integrated this configuration into IRONWARD. The Approach page distinguishes aggregate from single-request performance and defines the qualification plan. The earlier 120 tokens per second figure is withdrawn and not used.
- Does a one-million-token context mean the system understands everything?
- No. A context limit is capacity, not comprehension, retrieval reliability or correct security judgment. Long inputs increase processing time and can affect concurrent work. We must test relevant evidence retrieval and task outcomes, including distractors and adversarial content.
- Is the data guaranteed to stay in Hong Kong?
- That depends on the selected physical deployment, routing, logs, backups, update paths and support access. Local inference can keep model processing on controlled infrastructure. A Hong Kong-only or offline claim needs deployment evidence and an observed data-flow policy; it is not established by choosing a local model.
- Are the Spark machines a resilient production cluster?
- They are the planned local serving platform. Distributed inference may depend on all nodes and a shared head and cache. It is not automatically highly available. We need serving failure tests, monitoring, capacity management and an operating plan before committing to a service level.
- Why Redis rather than a conventional SQL database?
- Redis is the founder-selected primary state and messaging platform. The design defines authoritative records, persistence acknowledgements, no-eviction operation, write-once evidence references and recovery. Its suitability must be demonstrated under the required workload and fault cases. Speed alone is not a durability argument.
- Can it survive a kernel panic?
- That is a qualification objective. Files may survive while live process state does not. IRONWARD is designed to reconstruct tasks from durable records, fence stale workers and reconcile uncertain effects. Separate kernel, daemon, service and host failure tests are required before advertising recovery behaviour.
- How do you know the demo is real?
- Today it is a labelled design. Later, a qualified lab demonstration must carry exact software and model identities, actor and collector evidence, the authorised plan, the action record and independent containment plus benign-service results. A replay stays labelled as replay. We do not count shutting down the entire service as successful defence.
- Are the two attackers autonomous real attackers?
- They are planned bounded simulation agents in an owned isolated lab. One initiates the predefined scenario and the other runs defined follow-up challenges. The independent verifier judges the result. This tests a specific workflow, not coverage against arbitrary adversaries.
- What is the proprietary advantage?
- The prospective advantage is reliable integration and repeatable outcome verification, combined with operational experience and customer distribution. We must earn it through accepted work and pilots. There is no claim of a patent, exclusive model, unique Redis implementation or unassailable moat.
- How large is the market?
- We have not yet established a defensible numeric market estimate for this narrow product. We will size the reachable buyer segment from sourced counts and validated contract assumptions. We will not substitute the entire cybersecurity market for the initial serviceable segment.
- What are the economics?
- We need measured local and API cost per accepted task and actual support and onboarding effort. Local compute is not free. Pricing, margin and budget remain founder and pilot inputs.
- How much are you raising, and why Cyberport?
- A precise financial ask requires a monthly plan and a founder decision. The immediate proposed ask is help with suitable Hong Kong design partners, technical challenge and commercial mentorship. Relevant investor relationships can support later growth. Admission, funding and introductions are not assumed.
- Is IRONWARD a way to promote unrelated AI projects?
- IRONWARD must justify itself through a standalone customer problem, delivery plan and business case. AIFLOWLABS can transparently introduce its broader portfolio in a separate discussion. Product claims, customer data and project-specific resources remain distinct.
- Why should we trust the team?
- We will bring specific relevant work, verifiable outcomes and named responsibilities. AI coding agents are tools, not a substitute for accountable people. Verified biographies, local presence, references and operating commitments are founder inputs before submission.
- What would make you stop or change direction?
- Weak buyer urgency, poor verified task quality, unacceptable regression or unauthorised-effect behaviour, unsustainable support cost or inability to qualify the chosen infrastructure. Milestones should expose these facts early. Narrowing the workflow based on evidence is preferable to expanding a feature list without adoption.