diff --git a/source/development/architecture.rst b/source/development/architecture.rst
index a19bef13..c26dc712 100644
--- a/source/development/architecture.rst
+++ b/source/development/architecture.rst
@@ -56,11 +56,12 @@ The daemon listens on a unix domain socket and is capable of executing
 actions defined in it’s own configuration directory
 (“/usr/local/opnsense/service/conf/actions\_\*.conf”).
 
-Currently there are two types of services implemented in the daemon:
+Currently there are four types of services implemented in the daemon:
 
--  script : execute external (rc) scripts
--  inline : perform inline actions which are part of configd, currently
-   only template generation.
+-  script : execute external (rc) scripts, report back success or failure
+-  script_output: execute external scripts, report back their contents, usually in json format
+-  stream_output: open streams to backend components
+-  inline : perform inline actions which are part of configd, most notable template generation and maintanance.
 
 |
 | Template generation is handled by Jinja2 (http://jinja.pocoo.org/),
@@ -76,21 +77,18 @@ Frontend Architecture
 Routing
 -------
 
-The OPNsense framework uses components from Phalcon where possible; the
-first layer initializes Phalcon’s routing, which handles requests and
+The OPNsense framework uses standard components where possible; the
+first layer initializes routing, which handles requests and
 delivers them to the controller based on its url. User content is
-generated using Volt templates, which are picked by the controller.
-Because Phalcon’s default Models function with (relational) databases
-and we are using XML data, our model implementation is custom. But
-wherever possible we use components from Phalcon (for example,
-validation is handled using Phalcon’s classes). For a detailed
-description on the routing principles used in OPNsense, visit Frontend
+generated using Volt templates (using Phalcon), which are picked by the controller.
+
+For a detailed description on the routing principles used in OPNsense, visit Frontend
 :doc:`/development/frontend/routing`.
 
 Controllers and views
 ---------------------
 
-Not all parts of the framework are already implemented, but by deriving
+Not all parts of the framework are implemented, but by deriving
 all controllers from the base in the OPNsense project it’s easy to
 extend and adapt to future needs. Documentation on how to implement
 controllers, with the use of views, can be found at :doc:`/development/frontend/controller`.
diff --git a/source/development/frontend/controller.rst b/source/development/frontend/controller.rst
index 20bcb1c0..3fed4d7b 100644
--- a/source/development/frontend/controller.rst
+++ b/source/development/frontend/controller.rst
@@ -13,11 +13,9 @@ classes to ensure basic functionality such as authorisation and CSRF
 protection.
 
 Controllers are placed in the directory /usr/local/opnsense/mvc/app/controllers/<Vendor\_name>/<Module\_name>/
-and should use the standard Phalcon naming conventions, suffix Controller.php on
+and should use the folloging naming conventions, suffix Controller.php on
 every class file and suffix Action on all action methods.
 
-For a detailed description of how Controllers work in Phalcon, please
-look at the Phalcon documentation at http://docs.phalconphp.com/en/latest/reference/controllers.html
 
 ----------------------
 View based controllers
diff --git a/source/development/frontend/models_customfields.rst b/source/development/frontend/models_customfields.rst
index 800efc94..0efea7a2 100644
--- a/source/development/frontend/models_customfields.rst
+++ b/source/development/frontend/models_customfields.rst
@@ -13,7 +13,7 @@ Build the field type
     <?php
     namespace myVendorName\myModule;
     use OPNsense\Base\FieldTypes\BaseField;
-    use Phalcon\Validation\Validator\Regex;
+    use OPNsense\Base\Validators\Regex;
      
     class SimpleCustomField extends BaseField
     {