Built with a healthcare skill.
The skill version, settings and manifest supply the expected change. Gates 1–3 verify its source, named contributors and actual inventory, reconciling the build with what is observed in the org.
Forcia · The eight-gate method
An author’s claim.
A target-org fact.
Forcia’s deterministic harness checks finished Salesforce configuration, whoever authored it. One review record follows the change from its source to a human release.
Many authors. One review standard.
The build is finished.
The checks begin.
Built with your own tools.
Your admin, a contractor or another AI can bring the change. Gates 1–3 begin with org inspection to establish its source, contributors and inventory, then reconcile what was claimed with what is there.
Both continue through gates 4–8: assumptions, activation, target differences, the before-state and target-specific checks. The settings used to build a feature do not replace this review of the finished configuration.
The harness is designed for repeatable findings: the same change, recorded org state and check versions give the same findings. Missing evidence stays unresolved.
Eight gates. One careful passage.
From “I built it”
to “we checked it.”
The same eight-gate method applies to configuration built with a healthcare skill and to work authored elsewhere. Check the actual org, make exceptions visible, and give the human release owner evidence to act on.
Open a gate to see the question, the check, and the evidence it asks for.
01Find the real source.
Which org actually holds the work? Establish the source through inspection rather than relying on a description or a remembered sandbox name.Evidence: identified source org and observed change.
02Know who changed what.
Tie the examined changes to named principals and timestamps. Separate the author’s work from other contributors and platform-generated changes.Evidence: an attributed inventory with its inspection scope.
03Reconcile the whole change.
Does everything claimed exist? Is everything observed claimed, or set aside with a reason? Bring unexpected components and omissions into the review.Evidence: claims matched to observed changes and explained exceptions.
04Check the assumptions.
Verify the platform behavior the design relies on using vendor documentation or an appropriate org read. Keep anything unverified explicitly unresolved.Evidence: support for each material platform assumption.
05Make activation explicit.
What makes the new component take effect? Name the relevant trigger, invocation, schedule, permission assignment, page assignment, or configuration step.Evidence: the activation mechanism for each new component.
06See what else it touches.
Compare components with the target before replacing them. Review whole-file differences and dependencies so unrelated work is not hidden inside the change.Evidence: a reviewed target diff and the intended scope.
07Keep the before.
Retrieve and commit the target’s current state before applying the author’s version. Preserve a clear baseline for comparison and recovery planning.Evidence: a recorded target baseline preceding the overlay.
08Check against the target.
Verify target-dependent settings in the deploy target rather than inferring them from rehearsal. After human deployment, check the agreed behavior where the workflow will run.Evidence: target-specific checks, with timing and remaining verification explicit.
The record that connects it
One record.
From build to release.
This illustrative review record shows how a change’s claimed scope, source and target evidence, and unresolved questions can be kept together. The healthcare skill example shows one way a build can begin; its output still needs an independent review through Forcia.
The person reviewing it can approve, request more work or stop. Connected evidence tooling and automated checks are in development; the delivery method is used through Aegentra engagements.
Review record · Example 001
NSA IDR ticklers
Your choices, the build and its checks, together.
- Skill + settings
- Version and choices recorded
- Source + contributors
- Verification pending
- Setup checks
- Queue and calendar found; no setup conflicts
- Target baseline
- Verification pending
- Eight gates
- Review pending
- Production release
- With a person
A person reviews and releases it.
The checks reach
beyond the skill.
Changes from your team, a contractor, or another AI-assisted author follow the same review method. The prepared design and the surrounding changes still need org-specific checks.
People hold
production.
Production deployment is a human act. The product is designed around scoped agent capabilities and explicit human release authority.
Unknown stays
unknown.
Missing evidence, untested behavior, and exceptions remain visible. They belong in the decision, not under a green checkmark.