Richer behavior without surrendered control
Explore commanders that interpret changing conditions and propose useful action while the simulator keeps every real decision and consequence.
For Program and training leaders
Leading proof example · Training and simulation
Evaluate useful autonomy.
Keep the simulator in command.
Stark gives simulator OEMs, prime contractors, program teams, training leaders, and integration teams a practical way to evaluate agent behavior inside the software and authority model they already own.
Why training teams start here
Make autonomy visible before it enters your product.
Start with safer autonomy evaluation in BLACKBODY, then map the same governed boundary to an unclassified representative seam in your simulator.
Repeatable evaluation with observable decisions
See what each commander proposed, how policy responded, and what the simulation did next, so teams can compare runs and discuss behavior from shared facts.
For Simulator OEMs and evaluation teams
Integration control that stays with the delivery team
Add the runtime around partner-owned interfaces, domain logic, scenarios, and acceptance gates without replacing the simulator or changing customer ownership.
For Prime contractors and integration teams
Two capability-demonstration modes
See a person direct an agent. Then see two agents adapt.
Both BLACKBODY modes make proposals, policy decisions, and simulation consequences visible. Their public status comes from the sanitized evidence record.
01 / MODE
Human vs AI
Currently being builtLet an operator express intent in natural language while an autonomous opposing commander responds to the same evolving simulation.
- How it works
- A person types an objective, an agent translates that intent into a typed fleet-action proposal, and simulator policy accepts, rejects, constrains, or requests clarification before anything changes.
- Who decides
- The simulator retains state, time, scoring, policy, permissions, action admission, and every consequence.
02 / MODE
AI vs AI
Currently being builtObserve two autonomous commanders adapt to each other in one visible, repeatable mission run.
- How it works
- Each commander has an isolated identity, session, and tactical view while both use the same governed runtime to submit typed fleet-action proposals.
- Who decides
- The simulator remains authoritative over state, time, scoring, policy, permissions, action admission, and every consequence.
Evidence boundary: The mode labels above change only when the published evidence record satisfies the complete readiness gate. No page copy can promote a mode on its own.
Simulator-owned authority
Agents propose. Mission software decides.
Agent output is always a proposal. The simulator remains authoritative over state, time, scoring, policy, permissions, action admission, and consequence.
- State and time
- The simulator remains the source of truth for the world, its clock, and every state transition.
- Scoring and policy
- Native rules determine how behavior is evaluated and which proposals are allowed.
- Permissions and action admission
- The host exposes bounded choices by role and decides whether a proposal enters the simulation.
- Consequence
- Only the simulator applies an accepted action and records what actually happened.
Four boundaries, one honest offer
Know what you can reuse, what you can see, and what stays yours.
A capability demonstration should make the commercial and technical workshare clearer, not blur product, proof, integration, and acceptance together.
- Stark runtime
- The reusable governed agent foundation for model choice, roles, typed tools, permissions, lifecycle, and evidence boundaries.
- BLACKBODY demonstrator
- The Pinpoint-owned reference simulation that makes Human vs AI and AI vs AI behavior visible under simulator authority.
- Partner-owned integration
- The simulator, domain logic, scenarios, interfaces, customer relationship, and program delivery remain with the partner team.
- Deployment-specific acceptance
- Security, model suitability, mission effectiveness, offline behavior, and authorization are proven for the named environment by its responsible authorities.
From demonstration to bounded integration
Start with the smallest seam that can answer a real question.
The partner keeps its simulator and delivery role. Pinpoint brings the runtime and integration expertise needed to evaluate governed agents around that system.
- 01
Choose the evaluation question
Define the behavior, authority boundary, and observable outcome that would make a capability demonstration useful.
- 02
Map the simulator seam
Use an unclassified representative interface, scenario, and acceptance criteria to identify the smallest useful connection.
- 03
Keep integration ownership clear
Pinpoint shapes the governed agent boundary while the partner retains the simulator, domain behavior, and delivery decisions.
- 04
Qualify the named environment
Exercise the selected models, tools, failure cases, evidence needs, and program acceptance gates in the environment that will actually be evaluated.
Application patterns and roadmap opportunities
Build outward only after the core proof is ready.
These directions can shape future partner work. They are not claims of delivered simulation features or deployment acceptance.
Evidence-linked after-action review
Connect accepted decisions and simulation consequences to a concise review sequence for instructors and learners.
Adaptive scenario orchestration
Explore governed agents that propose scenario changes while instructor controls and simulator policy remain authoritative.
Synthetic role players
Shape bounded non-player roles around the context, tools, and decision rights appropriate to the exercise.
Instructor support
Assist instructors with observation, cueing, and review while people retain training judgment and release authority.
Technical-data assistance
Bring relevant manuals and engineering context into a controlled training workflow with source provenance intact.
Start with the capability
See the governed behavior.
Then choose the integration question.
Schedule a capability demonstration first. Any pilot discussion should use only unclassified, non-sensitive representative interfaces, scenarios, and acceptance criteria.