Product guides
Practical guides to connect evidence, understand relationships, record intent, and review change.
Start with your project brain, turn evidence into a roadmap and cycles, listen through community feature voting, and ask your project agent for a grounded next step. The architecture guides below help you inspect the system behind those decisions.
Connect your sources
Choose a repository, upload, cloud collector, or delivery integration.
Read your architecture map
Understand entities and relationships, then trace them to evidence.
Record and ratify intent
Make the decision, rationale, trade-offs, and guardrails explicit.
Review drift over time
Compare like-for-like observations and inspect what a change means.
A shared example
The guides use an API that delegates authentication to a gateway. The design is acceptable only while the gateway remains the route for all external requests. A later direct route changes that condition.
Follow the relationship.
A public route reaches the API directly.
Entities are the things. Relationships explain the system.
Select an entity to read what connects to it. An arrow has a direction and a meaning; it is more than a line between two boxes.
The service handles application requests and reads from the database. Authentication is delegated to the gateway by a human decision.
- Evidence
- server/database.py:24 · database client
- Recorded confidence
- 96% · code reference and connection configuration agree
Ask why a relationship is believed.
The same claim can have several supporting observations. Inspect the source, location, collection time, and any disagreement before relying on it.
- Code · declared application behavior
server/database.py:24 establishes the database client. infra/ingress.tf:16 declares a direct API route.
- Cloud · observed configuration
An ingress inventory collected on 22 September 2026 corroborates the public API route. This is configuration evidence, not a packet trace.
- CI/CD · delivery context
.gitlab-ci.yml:28 names the deployment target. A pipeline definition alone does not prove a successful production deployment.
People provide intent. Hyperoru preserves it.
“The API delegates authentication” is context. The decision to accept that design, its rationale, and the condition that makes it acceptable must come from a person.
- Named owner
- Maya Chen · fictional platform lead
- Rationale and trade-off
- Avoid duplicate authentication work and reduce request latency; accept dependence on the gateway boundary.
- Required guardrail
- Every external request must pass through the authenticating gateway.
The author and approval are supplied example data. No code observation can establish that Maya made this decision.
A change needs a baseline, current evidence, and a question.
The question here is whether a later public route bypasses the gateway boundary required by the human decision.
The new IaC route and cloud observation support a boundary change. Review that evidence against the ratified decision before choosing an action.
Make what is unknown as visible as what is known.
Coverage describes the evidence available for a particular review. It is separate from confidence in any one relationship.
All three expected source families are present in this example. That does not establish complete cloud-account coverage or runtime behavior. IaC is configuration evidence and remains distinct from a live cloud observation.
All records in this example are fictional. Your workspace derives its map from the sources you actually connect and keeps human decisions separate from observed facts.